diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/API/admin_api.md | 217 | ||||
| -rw-r--r-- | docs/API/differences_in_mastoapi_responses.md | 12 | ||||
| -rw-r--r-- | docs/API/pleroma_api.md | 20 | ||||
| -rw-r--r-- | docs/administration/CLI_tasks/config.md | 24 | ||||
| -rw-r--r-- | docs/administration/CLI_tasks/email.md | 24 | ||||
| -rw-r--r-- | docs/administration/backup.md | 34 | ||||
| -rw-r--r-- | docs/clients.md | 5 | ||||
| -rw-r--r-- | docs/configuration/cheatsheet.md | 66 | ||||
| -rw-r--r-- | docs/configuration/howto_user_recomendation.md | 31 | ||||
| -rw-r--r-- | docs/configuration/mrf.md | 45 | ||||
| -rw-r--r-- | docs/installation/openbsd_en.md | 22 | ||||
| -rw-r--r-- | docs/introduction.md | 70 |
12 files changed, 383 insertions, 187 deletions
diff --git a/docs/API/admin_api.md b/docs/API/admin_api.md index d98a78af0..47acd240e 100644 --- a/docs/API/admin_api.md +++ b/docs/API/admin_api.md @@ -3,7 +3,7 @@ Authentication is required and the user must be an admin. Configuration options: - + * `[:auth, :enforce_oauth_admin_scope_usage]` — OAuth admin scope requirement toggle. If `true`, admin actions explicitly demand admin OAuth scope(s) presence in OAuth token (client app must support admin scopes). If `false` and token doesn't have admin scope(s), `is_admin` user flag grants access to admin-specific actions. @@ -665,27 +665,14 @@ Note: Available `:permission_group` is currently moderator and admin. 404 is ret - 404 Not Found `"Not found"` - On success: 200 OK `{}` -## `GET /api/pleroma/admin/config/migrate_to_db` - -### Run mix task pleroma.config migrate_to_db - -Copy settings on key `:pleroma` to DB. - -- Params: none -- Response: - -```json -{} -``` - -## `GET /api/pleroma/admin/config/migrate_from_db` - -### Run mix task pleroma.config migrate_from_db +## `GET /api/pleroma/admin/restart` -Copy all settings from DB to `config/prod.exported_from_db.secret.exs` with deletion from DB. +### Restarts pleroma application - Params: none - Response: + - On failure: + - 400 Bad Request `"To use this endpoint you need to enable configuration from database."` ```json {} @@ -693,67 +680,139 @@ Copy all settings from DB to `config/prod.exported_from_db.secret.exs` with dele ## `GET /api/pleroma/admin/config` -### List config settings +### Get list of merged default settings with saved in database. -List config settings only works with `:pleroma => :instance => :dynamic_configuration` setting to `true`. +*If `need_reboot` flag exists in response, instance must be restarted, so reboot time settings can take effect.* -- Params: none +**Only works when configuration from database is enabled.** + +- Params: + - `only_db`: true (*optional*, get only saved in database settings) - Response: + - On failure: + - 400 Bad Request `"To use this endpoint you need to enable configuration from database."` ```json { - configs: [ + "configs": [ { - "group": string, - "key": string or string with leading `:` for atoms, - "value": string or {} or [] or {"tuple": []} + "group": ":pleroma", + "key": "Pleroma.Upload", + "value": [] } - ] + ], + "need_reboot": true } ``` + need_reboot - *optional*, if were changed reboot time settings. ## `POST /api/pleroma/admin/config` ### Update config settings -Updating config settings only works with `:pleroma => :instance => :dynamic_configuration` setting to `true`. -Module name can be passed as string, which starts with `Pleroma`, e.g. `"Pleroma.Upload"`. -Atom keys and values can be passed with `:` in the beginning, e.g. `":upload"`. -Tuples can be passed as `{"tuple": ["first_val", Pleroma.Module, []]}`. -`{"tuple": ["some_string", "Pleroma.Some.Module", []]}` will be converted to `{"some_string", Pleroma.Some.Module, []}`. -Keywords can be passed as lists with 2 child tuples, e.g. -`[{"tuple": ["first_val", Pleroma.Module]}, {"tuple": ["second_val", true]}]`. +*If `need_reboot` flag exists in response, instance must be restarted, so reboot time settings can take effect.* + +**Only works when configuration from database is enabled.** -If value contains list of settings `[subkey: val1, subkey2: val2, subkey3: val3]`, it's possible to remove only subkeys instead of all settings passing `subkeys` parameter. E.g.: -{"group": "pleroma", "key": "some_key", "delete": "true", "subkeys": [":subkey", ":subkey3"]}. +Some modifications are necessary to save the config settings correctly: -Compile time settings (need instance reboot): -- all settings by this keys: +- strings which start with `Pleroma.`, `Phoenix.`, `Tesla.` or strings like `Oban`, `Ueberauth` will be converted to modules; +``` +"Pleroma.Upload" -> Pleroma.Upload +"Oban" -> Oban +``` +- strings starting with `:` will be converted to atoms; +``` +":pleroma" -> :pleroma +``` +- objects with `tuple` key and array value will be converted to tuples; +``` +{"tuple": ["string", "Pleroma.Upload", []]} -> {"string", Pleroma.Upload, []} +``` +- arrays with *tuple objects* will be converted to keywords; +``` +[{"tuple": [":key1", "value"]}, {"tuple": [":key2", "value"]}] -> [key1: "value", key2: "value"] +``` + +Most of the settings will be applied in `runtime`, this means that you don't need to restart the instance. But some settings are applied in `compile time` and require a reboot of the instance, such as: +- all settings inside these keys: - `:hackney_pools` - `:chat` - - `Pleroma.Web.Endpoint` - - `Pleroma.Repo` -- part settings: - - `Pleroma.Captcha` -> `:seconds_valid` - - `Pleroma.Upload` -> `:proxy_remote` - - `:instance` -> `:upload_limit` - -- Params: - - `configs` => [ - - `group` (string) - - `key` (string or string with leading `:` for atoms) - - `value` (string, [], {} or {"tuple": []}) - - `delete` = true (optional, if parameter must be deleted) - - `subkeys` [(string with leading `:` for atoms)] (optional, works only if `delete=true` parameter is passed, otherwise will be ignored) +- partially settings inside these keys: + - `:seconds_valid` in `Pleroma.Captcha` + - `:proxy_remote` in `Pleroma.Upload` + - `:upload_limit` in `:instance` + +- Params: + - `configs` - array of config objects + - config object params: + - `group` - string (**required**) + - `key` - string (**required**) + - `value` - string, [], {} or {"tuple": []} (**required**) + - `delete` - true (*optional*, if setting must be deleted) + - `subkeys` - array of strings (*optional*, only works when `delete=true` parameter is passed, otherwise will be ignored) + +*When a value have several nested settings, you can delete only some nested settings by passing a parameter `subkeys`, without deleting all settings by key.* +``` +[subkey: val1, subkey2: val2, subkey3: val3] \\ initial value +{"group": ":pleroma", "key": "some_key", "delete": true, "subkeys": [":subkey", ":subkey3"]} \\ passing json for deletion +[subkey2: val2] \\ value after deletion +``` + +*Most of the settings can be partially updated through merge old values with new values, except settings value of which is list or is not keyword.* + +Example of setting without keyword in value: +```elixir +config :tesla, :adapter, Tesla.Adapter.Hackney +``` + +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}, + {:swarm, :node_blacklist}, + {:logger, :backends} ] +``` -- Request (example): +List of settings which support only full update by subkey: +```elixir +@full_subkey_update [ + {:pleroma, :assets, :mascots}, + {:pleroma, :emoji, :groups}, + {:pleroma, :workers, :retries}, + {:pleroma, :mrf_subchain, :match_actor}, + {:pleroma, :mrf_keyword, :replace} + ] +``` +*Settings without explicit key must be sended in separate config object params.* +```elixir +config :quack, + level: :debug, + meta: [:all], + ... +``` ```json { - configs: [ + "configs": [ + {"group": ":quack", "key": ":level", "value": ":debug"}, + {"group": ":quack", "key": ":meta", "value": [":all"]}, + ... + ] +} +``` +- Request: + +```json +{ + "configs": [ { - "group": "pleroma", + "group": ":pleroma", "key": "Pleroma.Upload", "value": [ {"tuple": [":uploader", "Pleroma.Uploaders.Local"]}, @@ -763,7 +822,7 @@ Compile time settings (need instance reboot): {"tuple": [":proxy_opts", [ {"tuple": [":redirect_on_failure", false]}, {"tuple": [":max_body_length", 1048576]}, - {"tuple": [":http": [ + {"tuple": [":http", [ {"tuple": [":follow_redirect", true]}, {"tuple": [":pool", ":upload"]}, ]]} @@ -779,18 +838,54 @@ Compile time settings (need instance reboot): ``` - Response: - + - On failure: + - 400 Bad Request `"To use this endpoint you need to enable configuration from database."` ```json { - configs: [ + "configs": [ { - "group": string, - "key": string or string with leading `:` for atoms, - "value": string or {} or [] or {"tuple": []} + "group": ":pleroma", + "key": "Pleroma.Upload", + "value": [...] } - ] + ], + "need_reboot": true } ``` +need_reboot - *optional*, if were changed reboot time settings. + +## ` GET /api/pleroma/admin/config/descriptions` + +### Get JSON with config descriptions. +Loads json generated from `config/descriptions.exs`. + +- Params: none +- Response: + +```json +[{ + "group": ":pleroma", // string + "key": "ModuleName", // string + "type": "group", // string or list with possible values, + "description": "Upload general settings", // string + "children": [ + { + "key": ":uploader", // string or module name `Pleroma.Upload` + "type": "module", + "description": "Module which will be used for uploads", + "suggestions": ["module1", "module2"] + }, + { + "key": ":filters", + "type": ["list", "module"], + "description": "List of filter modules for uploads", + "suggestions": [ + "module1", "module2", "module3" + ] + } + ] +}] +``` ## `GET /api/pleroma/admin/moderation_log` diff --git a/docs/API/differences_in_mastoapi_responses.md b/docs/API/differences_in_mastoapi_responses.md index bb62ed5f2..06de90f71 100644 --- a/docs/API/differences_in_mastoapi_responses.md +++ b/docs/API/differences_in_mastoapi_responses.md @@ -29,6 +29,7 @@ Has these additional fields under the `pleroma` object: - `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being it's mimetype. Currently the only alternate representation supported is `text/plain` - `expires_at`: a datetime (iso8601) that states when the post will expire (be deleted automatically), or empty if the post won't expire - `thread_muted`: true if the thread the post belongs to is muted +- `emoji_reactions`: A list with emoji / reaction maps. The format is `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint. ## Attachments @@ -87,6 +88,9 @@ Behavior has changed: - `/api/v1/accounts/search`: Does not require authentication +## Search (global) + +Unlisted posts are available in search results, they are considered to be public posts that shouldn't be shown in local/federated timeline. ## Notifications @@ -100,6 +104,14 @@ The `type` value is `move`. Has an additional field: - `target`: new account +### EmojiReact Notification + +The `type` value is `pleroma:emoji_reaction`. Has these fields: + +- `emoji`: The used emoji +- `account`: The account of the user who reacted +- `status`: The status that was reacted on + ## GET `/api/v1/notifications` Accepts additional parameters: diff --git a/docs/API/pleroma_api.md b/docs/API/pleroma_api.md index 689edbcc2..07e0af5e5 100644 --- a/docs/API/pleroma_api.md +++ b/docs/API/pleroma_api.md @@ -432,30 +432,30 @@ The status posting endpoint takes an additional parameter, `in_reply_to_conversa Emoji reactions work a lot like favourites do. They make it possible to react to a post with a single emoji character. -## `POST /api/v1/pleroma/statuses/:id/react_with_emoji` +## `PUT /api/v1/pleroma/statuses/:id/reactions/:emoji` ### React to a post with a unicode emoji -* Method: `POST` +* Method: `PUT` * Authentication: required * Params: `emoji`: A single character unicode emoji * Response: JSON, the status. -## `POST /api/v1/pleroma/statuses/:id/unreact_with_emoji` +## `DELETE /api/v1/pleroma/statuses/:id/reactions/:emoji` ### Remove a reaction to a post with a unicode emoji -* Method: `POST` +* Method: `DELETE` * Authentication: required * Params: `emoji`: A single character unicode emoji * Response: JSON, the status. -## `GET /api/v1/pleroma/statuses/:id/emoji_reactions_by` +## `GET /api/v1/pleroma/statuses/:id/reactions` ### Get an object of emoji to account mappings with accounts that reacted to the post * Method: `GET` * Authentication: optional * Params: None -* Response: JSON, a map of emoji to account list mappings. +* Response: JSON, a list of emoji/account list tuples, sorted by emoji insertion date, in ascending order, e.g, the first emoji in the list is the oldest. * Example Response: ```json -{ - "😀" => [{"id" => "xyz.."...}, {"id" => "zyx..."}], - "🗡" => [{"id" => "abc..."}] -} +[ + {"name": "😀", "count": 2, "me": true, "accounts": [{"id" => "xyz.."...}, {"id" => "zyx..."}]}, + {"name": "☕", "count": 1, "me": false, "accounts": [{"id" => "abc..."}]} +] ``` diff --git a/docs/administration/CLI_tasks/config.md b/docs/administration/CLI_tasks/config.md index e9d44b9a4..cc32bf859 100644 --- a/docs/administration/CLI_tasks/config.md +++ b/docs/administration/CLI_tasks/config.md @@ -1,12 +1,16 @@ # Transfering the config to/from the database -!!! danger - This is a Work In Progress, not usable just yet. - {! backend/administration/CLI_tasks/general_cli_task_info.include !} ## Transfer config from file to DB. +!!! note + You need to add the following to your config before executing this command: + + ```elixir + config :pleroma, configurable_from_database: true + ``` + ```sh tab="OTP" ./bin/pleroma_ctl config migrate_to_db ``` @@ -18,11 +22,19 @@ mix pleroma.config migrate_to_db ## Transfer config from DB to `config/env.exported_from_db.secret.exs` +!!! note + In-Database configuration will still be applied after executing this command unless you set the following in your config: + + ```elixir + config :pleroma, configurable_from_database: false + ``` + +To delete transfered settings from database optional flag `-d` can be used. `<env>` is `prod` by default. + ```sh tab="OTP" - ./bin/pleroma_ctl config migrate_from_db <env> + ./bin/pleroma_ctl config migrate_from_db [--env=<env>] [-d] ``` ```sh tab="From Source" -mix pleroma.config migrate_from_db <env> +mix pleroma.config migrate_from_db [--env=<env>] [-d] ``` - diff --git a/docs/administration/CLI_tasks/email.md b/docs/administration/CLI_tasks/email.md new file mode 100644 index 000000000..7b7a8457a --- /dev/null +++ b/docs/administration/CLI_tasks/email.md @@ -0,0 +1,24 @@ +# Managing emails + +{! backend/administration/CLI_tasks/general_cli_task_info.include !} + +## Send test email (instance email by default) + +```sh tab="OTP" + ./bin/pleroma_ctl email test [--to <destination email address>] +``` + +```sh tab="From Source" +mix pleroma.email test [--to <destination email address>] +``` + + +Example: + +```sh tab="OTP" +./bin/pleroma_ctl email test --to root@example.org +``` + +```sh tab="From Source" +mix pleroma.email test --to root@example.org +``` diff --git a/docs/administration/backup.md b/docs/administration/backup.md index 2c70e7bf8..685c45128 100644 --- a/docs/administration/backup.md +++ b/docs/administration/backup.md @@ -1,17 +1,35 @@ -# Backup/Restore your instance +# Backup/Restore/Move/Remove your instance ## Backup 1. Stop the Pleroma service. 2. Go to the working directory of Pleroma (default is `/opt/pleroma`) -3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>` +3. Run `sudo -Hu postgres pg_dump -d <pleroma_db> --format=custom -f </path/to/backup_location/pleroma.pgdump>` (make sure the postgres user has write access to the destination file) 4. Copy `pleroma.pgdump`, `config/prod.secret.exs` and the `uploads` folder to your backup destination. If you have other modifications, copy those changes too. 5. Restart the Pleroma service. -## Restore +## Restore/Move -1. Stop the Pleroma service. -2. Go to the working directory of Pleroma (default is `/opt/pleroma`) -3. Copy the above mentioned files back to their original position. -4. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>` -5. Restart the Pleroma service. +1. Optionally reinstall Pleroma (either on the same server or on another server if you want to move servers). Try to use the same database name. +2. Stop the Pleroma service. +3. Go to the working directory of Pleroma (default is `/opt/pleroma`) +4. Copy the above mentioned files back to their original position. +5. Drop the existing database and recreate an empty one `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'CREATE DATABASE <pleroma_db>;';` +6. Run `sudo -Hu postgres pg_restore -d <pleroma_db> -v -1 </path/to/backup_location/pleroma.pgdump>` +7. If you installed a newer Pleroma version, you should run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any. +8. Restart the Pleroma service. + +[^1]: Prefix with `MIX_ENV=prod` to run it using the production config file. + +## Remove + +1. Optionally you can remove the users of your instance. This will trigger delete requests for their accounts and posts. Note that this is 'best effort' and doesn't mean that all traces of your instance will be gone from the fediverse. + * You can do this from the admin-FE where you can select all local users and delete the accounts using the *Moderate multiple users* dropdown. + * You can also list local users and delete them individualy using the CLI tasks for [Managing users](./CLI_tasks/user.md). +2. Stop the Pleroma service `systemctl stop pleroma` +3. Disable pleroma from systemd `systemctl disable pleroma` +4. Remove the files and folders you created during installation (see installation guide). This includes the pleroma, nginx and systemd files and folders. +5. Reload nginx now that the configuration is removed `systemctl reload nginx` +6. Remove the database and database user `sudo -Hu postgres psql -c 'DROP DATABASE <pleroma_db>;';` `sudo -Hu postgres psql -c 'DROP USER <pleroma_db>;';` +7. Remove the system user `userdel pleroma` +8. Remove the dependencies that you don't need anymore (see installation guide). Make sure you don't remove packages that are still needed for other software that you have running! diff --git a/docs/clients.md b/docs/clients.md index 6c6180f7a..8ac9ad3de 100644 --- a/docs/clients.md +++ b/docs/clients.md @@ -37,6 +37,11 @@ Feel free to contact us to be added to this list! - Platforms: Android - Features: Streaming Ready, Moderation, Text Formatting +### Kyclos +- Source Code: <https://git.pleroma.social/pleroma/harbour-kyclos> +- Platforms: SailfishOS +- Features: No Streaming + ### Nekonium - Homepage: [F-Droid Repository](https://repo.gdgd.jp.net/), [Google Play](https://play.google.com/store/apps/details?id=com.apps.nekonium), [Amazon](https://www.amazon.co.jp/dp/B076FXPRBC/) - Source: <https://gogs.gdgd.jp.net/lin/nekonium> diff --git a/docs/configuration/cheatsheet.md b/docs/configuration/cheatsheet.md index cad3af68d..c9559fe85 100644 --- a/docs/configuration/cheatsheet.md +++ b/docs/configuration/cheatsheet.md @@ -69,11 +69,7 @@ You shouldn't edit the base config directly to avoid breakages and merge conflic * `account_field_name_length`: An account field name maximum length (default: `512`). * `account_field_value_length`: An account field value maximum length (default: `2048`). * `external_user_synchronization`: Enabling following/followers counters synchronization for external users. - -!!! danger - This is a Work In Progress, not usable just yet - -* `dynamic_configuration`: Allow transferring configuration to DB with the subsequent customization from Admin api. +* `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. ## Federation ### MRF policies @@ -313,16 +309,15 @@ This will make Pleroma listen on `127.0.0.1` port `8080` and generate urls start Available options: * `enabled` - Enable/disable the plug. Defaults to `false`. -* `headers` - A list of strings naming the `req_headers` to use when deriving the `remote_ip`. Order does not matter. Defaults to `~w[forwarded x-forwarded-for x-client-ip x-real-ip]`. +* `headers` - A list of strings naming the `req_headers` to use when deriving the `remote_ip`. Order does not matter. Defaults to `["x-forwarded-for"]`. * `proxies` - A list of strings in [CIDR](https://en.wikipedia.org/wiki/CIDR) notation specifying the IPs of known proxies. Defaults to `[]`. * `reserved` - Defaults to [localhost](https://en.wikipedia.org/wiki/Localhost) and [private network](https://en.wikipedia.org/wiki/Private_network). ### :rate_limit -This is an advanced feature and disabled by default. - -If your instance is behind a reverse proxy you must enable and configure [`Pleroma.Plugs.RemoteIp`](#pleroma-plugs-remoteip). +!!! note + If your instance is behind a reverse proxy ensure [`Pleroma.Plugs.RemoteIp`](#pleroma-plugs-remoteip) is enabled (it is enabled by default). A keyword list of rate limiters where a key is a limiter name and value is the limiter configuration. The basic configuration is a tuple where: @@ -331,14 +326,31 @@ A keyword list of rate limiters where a key is a limiter name and value is the l It is also possible to have different limits for unauthenticated and authenticated users: the keyword value must be a list of two tuples where the first one is a config for unauthenticated users and the second one is for authenticated. +For example: + +```elixir +config :pleroma, :rate_limit, + authentication: {60_000, 15}, + search: [{1000, 10}, {1000, 30}] +``` + +Means that: + +1. In 60 seconds, 15 authentication attempts can be performed from the same IP address. +2. In 1 second, 10 search requests can be performed from the same IP adress by unauthenticated users, while authenticated users can perform 30 search requests per second. + Supported rate limiters: -* `:search` for the search requests (account & status search etc.) -* `:app_account_creation` for registering user accounts from the same IP address -* `:relations_actions` for actions on relations with all users (follow, unfollow) -* `:relation_id_action` for actions on relation with a specific user (follow, unfollow) -* `:statuses_actions` for create / delete / fav / unfav / reblog / unreblog actions on any statuses -* `:status_id_action` for fav / unfav or reblog / unreblog actions on the same status by the same user +* `:search` - Account/Status search. +* `:app_account_creation` - Account registration from the API. +* `:relations_actions` - Following/Unfollowing in general. +* `:relation_id_action` - Following/Unfollowing for a specific user. +* `:statuses_actions` - Status actions such as: (un)repeating, (un)favouriting, creating, deleting. +* `:status_id_action` - (un)Repeating/(un)Favouriting a particular status. +* `:authentication` - Authentication actions, i.e getting an OAuth token. +* `:password_reset` - Requesting password reset emails. +* `:account_confirmation_resend` - Requesting resending account confirmation emails. +* `:ap_routes` - Requesting statuses via ActivityPub. ### :web_cache_ttl @@ -355,7 +367,7 @@ Available caches: * `proxy_url`: an upstream proxy to fetch posts and/or media with, (default: `nil`) * `send_user_agent`: should we include a user agent with HTTP requests? (default: `true`) -* `user_agent`: what user agent should we use? (default: `:default`), must be string or `:default` +* `user_agent`: what user agent should we use? (default: `:default`), must be string or `:default` * `adapter`: array of hackney options @@ -489,6 +501,10 @@ Email notifications settings. - `:logo` - a path to a custom logo. Set it to `nil` to use the default Pleroma logo. - `:styling` - a map with color settings for email templates. +### Pleroma.Emails.NewUsersDigestEmail + +- `:enabled` - a boolean, enables new users admin digest email when `true`. Defaults to `false`. + ## Background jobs ### Oban @@ -501,6 +517,7 @@ Configuration options described in [Oban readme](https://github.com/sorentwo/oba * `verbose` - logs verbosity * `prune` - non-retryable jobs [pruning settings](https://github.com/sorentwo/oban#pruning) (`:disabled` / `{:maxlen, value}` / `{:maxage, value}`) * `queues` - job queues (see below) +* `crontab` - periodic jobs, see [`Oban.Cron`](#obancron) Pleroma has the following queues: @@ -512,6 +529,12 @@ Pleroma has the following queues: * `web_push` - Web push notifications * `scheduled_activities` - Scheduled activities, see [`Pleroma.ScheduledActivity`](#pleromascheduledactivity) +#### Oban.Cron + +Pleroma has these periodic job workers: + +`Pleroma.Workers.Cron.ClearOauthTokenWorker` - a job worker to cleanup expired oauth tokens. + Example: ```elixir @@ -522,6 +545,9 @@ config :pleroma, Oban, queues: [ federator_incoming: 50, federator_outgoing: 50 + ], + crontab: [ + {"0 0 * * *", Pleroma.Workers.Cron.ClearOauthTokenWorker} ] ``` @@ -804,8 +830,7 @@ Configure OAuth 2 provider capabilities: * `token_expires_in` - The lifetime in seconds of the access token. * `issue_new_refresh_token` - Keeps old refresh token or generate new refresh token when to obtain an access token. -* `clean_expired_tokens` - Enable a background job to clean expired oauth tokens. Defaults to `false`. -* `clean_expired_tokens_interval` - Interval to run the job to clean expired tokens. Defaults to `86_400_000` (24 hours). +* `clean_expired_tokens` - Enable a background job to clean expired oauth tokens. Defaults to `false`. Interval settings sets in configuration periodic jobs [`Oban.Cron`](#obancron) ## Link parsing @@ -841,3 +866,8 @@ config :auto_linker, ## Custom Runtime Modules (`:modules`) * `runtime_dir`: A path to custom Elixir modules (such as MRF policies). + + +## :configurable_from_database + +Boolean, enables/disables in-database configuration. Read [Transfering the config to/from the database](../administration/CLI_tasks/config.md) for more information. diff --git a/docs/configuration/howto_user_recomendation.md b/docs/configuration/howto_user_recomendation.md deleted file mode 100644 index c4d749d0c..000000000 --- a/docs/configuration/howto_user_recomendation.md +++ /dev/null @@ -1,31 +0,0 @@ -# How to activate user recommendation (Who to follow panel) - - -To show the *who to follow* panel, edit `config/prod.secret.exs` in the Pleroma backend. Following code activates the *who to follow* panel: - -```elixir -config :pleroma, :suggestions, - enabled: true, - third_party_engine: - "http://vinayaka.distsn.org/cgi-bin/vinayaka-user-match-suggestions-api.cgi?{{host}}+{{user}}", - timeout: 300_000, - limit: 40, - web: "https://vinayaka.distsn.org" - -``` - -`config/config.exs` already includes this code, but `enabled:` is `false`. - -`/api/v1/suggestions` is also provided when *who to follow* panel is enabled. - -For advanced customization, following code shows the newcomers of the fediverse at the *who to follow* panel: - -```elixir -config :pleroma, :suggestions, - enabled: true, - third_party_engine: - "http://vinayaka.distsn.org/cgi-bin/vinayaka-user-new-suggestions-api.cgi?{{host}}+{{user}}", - timeout: 60_000, - limit: 40, - web: "https://vinayaka.distsn.org/user-new.html" -``` diff --git a/docs/configuration/mrf.md b/docs/configuration/mrf.md index 45be18fc5..c3957c255 100644 --- a/docs/configuration/mrf.md +++ b/docs/configuration/mrf.md @@ -1,4 +1,5 @@ # Message Rewrite Facility + The Message Rewrite Facility (MRF) is a subsystem that is implemented as a series of hooks that allows the administrator to rewrite or discard messages. Possible uses include: @@ -10,7 +11,8 @@ Possible uses include: * removing media from messages * sending only public messages to a specific instance -The MRF provides user-configurable policies. The default policy is `NoOpPolicy`, which disables the MRF functionality. Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module. +The MRF provides user-configurable policies. The default policy is `NoOpPolicy`, which disables the MRF functionality. Pleroma also includes an easy to use policy called `SimplePolicy` which maps messages matching certain pre-defined criterion to actions built into the policy module. + It is possible to use multiple, active MRF policies at the same time. ## Quarantine Instances @@ -18,7 +20,8 @@ It is possible to use multiple, active MRF policies at the same time. You have the ability to prevent from private / followers-only messages from federating with specific instances. Which means they will only get the public or unlisted messages from your instance. If, for example, you're using `MIX_ENV=prod` aka using production mode, you would open your configuration file located in `config/prod.secret.exs` and edit or add the option under your `:instance` config object. Then you would specify the instance within quotes. -``` + +```elixir config :pleroma, :instance, [...] quarantined_instances: ["instance.example", "other.example"] @@ -28,15 +31,15 @@ config :pleroma, :instance, `SimplePolicy` is capable of handling most common admin tasks. -To use `SimplePolicy`, you must enable it. Do so by adding the following to your `:instance` config object, so that it looks like this: +To use `SimplePolicy`, you must enable it. Do so by adding the following to your `:instance` config object, so that it looks like this: -``` +```elixir config :pleroma, :instance, [...] rewrite_policy: Pleroma.Web.ActivityPub.MRF.SimplePolicy ``` -Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object. These groups are: +Once `SimplePolicy` is enabled, you can configure various groups in the `:mrf_simple` config object. These groups are: * `media_removal`: Servers in this group will have media stripped from incoming messages. * `media_nsfw`: Servers in this group will have the #nsfw tag and sensitive setting injected into incoming messages which contain media. @@ -50,7 +53,7 @@ Servers should be configured as lists. This example will enable `SimplePolicy`, block media from `illegalporn.biz`, mark media as NSFW from `porn.biz` and `porn.business`, reject messages from `spam.com`, remove messages from `spam.university` from the federated timeline and block reports (flags) from `whiny.whiner`: -``` +```elixir config :pleroma, :instance, rewrite_policy: [Pleroma.Web.ActivityPub.MRF.SimplePolicy] @@ -60,30 +63,31 @@ config :pleroma, :mrf_simple, reject: ["spam.com"], federated_timeline_removal: ["spam.university"], report_removal: ["whiny.whiner"] - ``` ### Use with Care -The effects of MRF policies can be very drastic. It is important to use this functionality carefully. Always try to talk to an admin before writing an MRF policy concerning their instance. +The effects of MRF policies can be very drastic. It is important to use this functionality carefully. Always try to talk to an admin before writing an MRF policy concerning their instance. ## Writing your own MRF Policy -As discussed above, the MRF system is a modular system that supports pluggable policies. This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting. +As discussed above, the MRF system is a modular system that supports pluggable policies. This means that an admin may write a custom MRF policy in Elixir or any other language that runs on the Erlang VM, by specifying the module name in the `rewrite_policy` config setting. For example, here is a sample policy module which rewrites all messages to "new message content": ```elixir -# This is a sample MRF policy which rewrites all Notes to have "new message -# content." -defmodule Site.RewritePolicy do - @behavior Pleroma.Web.ActivityPub.MRF +defmodule Pleroma.Web.ActivityPub.MRF.RewritePolicy do + @moduledoc "MRF policy which rewrites all Notes to have 'new message content'." + @behaviour Pleroma.Web.ActivityPub.MRF # Catch messages which contain Note objects with actual data to filter. # Capture the object as `object`, the message content as `content` and the # message itself as `message`. @impl true - def filter(%{"type" => Create", "object" => {"type" => "Note", "content" => content} = object} = message) + def filter( + %{"type" => "Create", "object" => %{"type" => "Note", "content" => content} = object} = + message + ) when is_binary(content) do # Subject / CW is stored as summary instead of `name` like other AS2 objects # because of Mastodon doing it that way. @@ -106,17 +110,22 @@ defmodule Site.RewritePolicy do # Let all other messages through without modifying them. @impl true def filter(message), do: {:ok, message} + + @impl true + def describe do + {:ok, %{mrf_sample: %{content: "new message content"}}}` + end end ``` -If you save this file as `lib/site/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma. You can enable it in the configuration like so: +If you save this file as `lib/pleroma/web/activity_pub/mrf/rewrite_policy.ex`, it will be included when you next rebuild Pleroma. You can enable it in the configuration like so: -``` +```elixir config :pleroma, :instance, rewrite_policy: [ Pleroma.Web.ActivityPub.MRF.SimplePolicy, - Site.RewritePolicy + Pleroma.Web.ActivityPub.MRF.RewritePolicy ] ``` -Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL. As such, you are obligated to release the sources to your custom MRF policy modules upon request. +Please note that the Pleroma developers consider custom MRF policy modules to fall under the purview of the AGPL. As such, you are obligated to release the sources to your custom MRF policy modules upon request. diff --git a/docs/installation/openbsd_en.md b/docs/installation/openbsd_en.md index 45602bd75..e8c5d844c 100644 --- a/docs/installation/openbsd_en.md +++ b/docs/installation/openbsd_en.md @@ -1,6 +1,6 @@ # Installing on OpenBSD -This guide describes the installation and configuration of pleroma (and the required software to run it) on a single OpenBSD 6.4 server. +This guide describes the installation and configuration of pleroma (and the required software to run it) on a single OpenBSD 6.6 server. For any additional information regarding commands and configuration files mentioned here, check the man pages [online](https://man.openbsd.org/) or directly on your server with the man command. @@ -40,7 +40,12 @@ Enter a shell as the \_pleroma user. As root, run `su _pleroma -;cd`. Then clone #### PostgreSQL Start a shell as the \_postgresql user (as root run `su _postgresql -` then run the `initdb` command to initialize postgresql: -If you wish to not use the default location for postgresql's data (/var/postgresql/data), add the following switch at the end of the command: `-D <path>` and modify the `datadir` variable in the /etc/rc.d/postgresql script. +You will need to specify pgdata directory to the default (/var/postgresql/data) with the `-D <path>` and set the user to postgres with the `-U <username>` flag. This can be done as follows: + +``` +initdb -D /var/postgresql/data -U postgres +``` +If you are not using the default directory, you will have to update the `datadir` variable in the /etc/rc.d/postgresql script. When this is done, enable postgresql so that it starts on boot and start it. As root, run: ``` @@ -81,7 +86,6 @@ server "default" { } types { - include "/usr/share/misc/mime.types" } ``` Do not forget to change *<IPv4/6 address\>* to your server's address(es). If httpd should only listen on one protocol family, comment one of the two first *listen* options. @@ -103,7 +107,7 @@ Insert the following configuration in /etc/acme-client.conf: authority letsencrypt-<domain name> { #agreement url "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf" - api url "https://acme-v01.api.letsencrypt.org/directory" + api url "https://acme-v02.api.letsencrypt.org/directory" account key "/etc/acme/letsencrypt-privkey-<domain name>.pem" } @@ -222,7 +226,7 @@ Then follow the main installation guide: * run `mix deps.get` * run `mix pleroma.instance gen` and enter your instance's information when asked * copy config/generated\_config.exs to config/prod.secret.exs. The default values should be sufficient but you should edit it and check that everything seems OK. - * exit your current shell back to a root one and run `psql -U postgres -f /home/_pleroma/config/setup_db.psql` to setup the database. + * exit your current shell back to a root one and run `psql -U postgres -f /home/_pleroma/pleroma/config/setup_db.psql` to setup the database. * return to a \_pleroma shell into pleroma's installation directory (`su _pleroma -;cd ~/pleroma`) and run `MIX_ENV=prod mix ecto.migrate` As \_pleroma in /home/\_pleroma/pleroma, you can now run `LC_ALL=en_US.UTF-8 MIX_ENV=prod mix phx.server` to start your instance. @@ -230,3 +234,11 @@ In another SSH session/tmux window, check that it is working properly by running ##### Starting pleroma at boot An rc script to automatically start pleroma at boot hasn't been written yet, it can be run in a tmux session (tmux is in base). + + +#### Create administrative user + +If your instance is up and running, you can create your first user with administrative rights with the following command as the \_pleroma user. +``` +LC_ALL=en_US.UTF-8 MIX_ENV=prod mix pleroma.user new <username> <your@emailaddress> --admin +``` diff --git a/docs/introduction.md b/docs/introduction.md index 045dc7c05..823e14f53 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -3,53 +3,63 @@ Pleroma is a federated social networking platform, compatible with GNU social, Mastodon and other OStatus and ActivityPub implementations. It is free software licensed under the AGPLv3. It actually consists of two components: a backend, named simply Pleroma, and a user-facing frontend, named Pleroma-FE. It also includes the Mastodon frontend, if that's your thing. It's part of what we call the fediverse, a federated network of instances which speak common protocols and can communicate with each other. -One account on a instance is enough to talk to the entire fediverse! +One account on an instance is enough to talk to the entire fediverse! ## How can I use it? -Pleroma instances are already widely deployed, a list can be found here: -http://distsn.org/pleroma-instances.html +Pleroma instances are already widely deployed, a list can be found at <http://distsn.org/pleroma-instances.html>. Information on all existing fediverse instances can be found at <https://fediverse.network/>. If you don't feel like joining an existing instance, but instead prefer to deploy your own instance, that's easy too! -Installation instructions can be found here: -[main Pleroma wiki](/) +Installation instructions can be found in the installation section of these docs. ## I got an account, now what? -Great! Now you can explore the fediverse! -- Open the login page for your Pleroma instance (for ex. https://pleroma.soykaf.com) and login with your username and password. -(If you don't have one yet, click on Register) :slightly_smiling_face: +Great! Now you can explore the fediverse! Open the login page for your Pleroma instance (e.g. <https://pleroma.soykaf.com>) and login with your username and password. (If you don't have an account yet, click on Register) At this point you will have two columns in front of you. ### Left column -- first block: here you can see your avatar, your nickname a bio, and statistics (Statuses, Following, Followers). -Under that you have a text form which allows you to post new statuses. The icon on the left is for uploading media files and attach them to your post. The number under the text form is a character counter, every instance can have a different character limit (the default is 5000). -If you want to mention someone, type @ + name of the person. A drop-down menu will help you in finding the right person. :slight_smile: + +- first block: here you can see your avatar, your nickname and statistics (Statuses, Following, Followers). Clicking your profile pic will open your profile. +Under that you have a text form which allows you to post new statuses. The number on the bottom of the text form is a character counter, every instance can have a different character limit (the default is 5000). +If you want to mention someone, type @ + name of the person. A drop-down menu will help you in finding the right person. +Under the text form there are also several visibility options and there is the option to use rich text. +Under that the icon on the left is for uploading media files and attach them to your post. There is also an emoji-picker and an option to post a poll. To post your status, simply press Submit. +On the top right you will also see a wrench icon. This opens your personal settings. - second block: Here you can switch between the different timelines: - - Timeline: all the people that you follow - - Mentions: all the statutes where you are mentioned - - Public Timeline: all the statutes from the local instance - - The Whole Known Network: everything, local and remote! - -- third block: this is the Chat block, where you communicate with people on the same instance in realtime. It is local-only, for now, but we're planning to make it extendable to the entire fediverse! :sweat_smile: - + - Timeline: all the people that you follow + - Interactions: here you can switch between different timelines where there was interaction with your account. There is Mentions, Repeats and Favorites, and New follows + - Direct Messages: these are the Direct Messages sent to you + - Public Timeline: all the statutes from the local instance + - The Whole Known Network: all public posts the instance knows about, both local and remote! + - About: This isn't a Timeline but shows relevant info about the instance. You can find a list of the moderators and admins, Terms of Service, MRF policies and enabled features. +- Optional third block: This is the Instance panel that can be activated, but is deactivated by default. It's fully customisable and by default has links to the pleroma-fe and Mastodon-fe. - fourth block: This is the Notifications block, here you will get notified whenever somebody mentions you, follows you, repeats or favorites one of your statuses. ### Right column -This is where the interesting stuff happens! :slight_smile: +This is where the interesting stuff happens! Depending on the timeline you will see different statuses, but each status has a standard structure: -- Icon + name + link to profile. An optional left-arrow if it's a reply to another status (hovering will reveal the replied-to status). -- A + button on the right allows you to Expand/Collapse an entire discussion thread. It also updates in realtime! -- A binocular icon allows you to open the status on the instance where it's originating from. -- The text of the status, including mentions. If you click on a mention, it will automatically open the profile page of that person. -- Four buttons (left to right): Reply, Repeat, Favorite, Delete. - -## Mastodon interface -If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we got that too! :smile: -Just add a "/web" after your instance url (for ex. https://pleroma.soycaf.com/web) and you'll end on the Mastodon web interface, but with a Pleroma backend! MAGIC! :fireworks: -For more information on the Mastodon interface, please look here: -https://github.com/tootsuite/documentation/blob/master/Using-Mastodon/User-guide.md + +- Profile pic, name and link to profile. An optional left-arrow if it's a reply to another status (hovering will reveal the replied-to status). Clicking on the profile pic will uncollapse the user's profile. +- A `+` button on the right allows you to Expand/Collapse an entire discussion thread. It also updates in realtime! +- An arrow icon allows you to open the status on the instance where it's originating from. +- The text of the status, including mentions and attachements. If you click on a mention, it will automatically open the profile page of that person. +- Three buttons (left to right): Reply, Repeat, Favorite. There is also a forth button, this is a dropdown menu for simple moderation like muting the conversation or, if you have moderation rights, delete the status from the server. + +### Top right + +- The magnifier icon opens the search screen where you can search for statuses, people and hashtags. It's also possible to import statusses from remote servers by pasting the url to the post in the search field. +- The gear icon gives you general settings +- If you have admin rights, you'll see an icon that opens the admin interface +- The last icon is to log out + +### Bottom right +On the bottom right you have a chatbox. Here you can communicate with people on the same instance in realtime. It is local-only, for now, but there are plans to make it extendable to the entire fediverse! + +### Mastodon interface +If the Pleroma interface isn't your thing, or you're just trying something new but you want to keep using the familiar Mastodon interface, we got that too! +Just add a "/web" after your instance url (e.g. <https://pleroma.soycaf.com/web>) and you'll end on the Mastodon web interface, but with a Pleroma backend! MAGIC! +The Mastodon interface is from the Glitch-soc fork. For more information on the Mastodon interface you can check the [Mastodon](https://docs.joinmastodon.org/) and [Glitch-soc](https://glitch-soc.github.io/docs/) documentation. Remember, what you see is only the frontend part of Mastodon, the backend is still Pleroma. |