summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorAlex Gleason <alex@alexgleason.me>2020-09-11 14:13:38 -0500
committerAlex Gleason <alex@alexgleason.me>2020-09-11 14:13:38 -0500
commit9733c9d06563a92e4c58ac906c5f98b617b9e731 (patch)
treeabbf03ddb917c1c203cb79eab64647d3af541fff /docs
parentdfb831ca39db3098d6d585448a6ff8e938e51e8c (diff)
parent9fb88c814ddadd9138ef29550a856938491a1ca4 (diff)
Merge remote-tracking branch 'upstream/develop' into chat-moderation
Diffstat (limited to 'docs')
-rw-r--r--docs/administration/updating.md7
-rw-r--r--docs/configuration/cheatsheet.md22
2 files changed, 19 insertions, 10 deletions
diff --git a/docs/administration/updating.md b/docs/administration/updating.md
index c994f3f16..ef2c9218c 100644
--- a/docs/administration/updating.md
+++ b/docs/administration/updating.md
@@ -18,9 +18,10 @@ su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate"
1. Go to the working directory of Pleroma (default is `/opt/pleroma`)
2. Run `git pull`. This pulls the latest changes from upstream.
-3. Run `mix deps.get`. This pulls in any new dependencies.
+3. Run `mix deps.get` [^1]. This pulls in any new dependencies.
4. Stop the Pleroma service.
-5. Run `mix ecto.migrate`[^1]. This task performs database migrations, if there were any.
+5. Run `mix ecto.migrate` [^1] [^2]. This task performs database migrations, if there were any.
6. Start the Pleroma service.
-[^1]: Prefix with `MIX_ENV=prod` to run it using the production config file.
+[^1]: Depending on which install guide you followed (for example on Debian/Ubuntu), you want to run `mix` tasks as `pleroma` user by adding `sudo -Hu pleroma` before the command.
+[^2]: Prefix with `MIX_ENV=prod` to run it using the production config file.
diff --git a/docs/configuration/cheatsheet.md b/docs/configuration/cheatsheet.md
index b2980793d..7cf1d1ce7 100644
--- a/docs/configuration/cheatsheet.md
+++ b/docs/configuration/cheatsheet.md
@@ -115,6 +115,7 @@ To add configuration to your config file, you can copy it from the base config.
* `Pleroma.Web.ActivityPub.MRF.VocabularyPolicy`: Restricts activities to a configured set of vocabulary. (See [`:mrf_vocabulary`](#mrf_vocabulary)).
* `Pleroma.Web.ActivityPub.MRF.ObjectAgePolicy`: Rejects or delists posts based on their age when received. (See [`:mrf_object_age`](#mrf_object_age)).
* `Pleroma.Web.ActivityPub.MRF.ActivityExpirationPolicy`: Sets a default expiration on all posts made by users of the local instance. Requires `Pleroma.ActivityExpiration` to be enabled for processing the scheduled delections.
+ * `Pleroma.Web.ActivityPub.MRF.ForceBotUnlistedPolicy`: Makes all bot posts to disappear from public timelines.
* `transparency`: Make the content of your Message Rewrite Facility settings public (via nodeinfo).
* `transparency_exclusions`: Exclude specific instance names from MRF transparency. The use of the exclusions feature will be disclosed in nodeinfo as a boolean value.
@@ -496,7 +497,7 @@ Settings for HTTP connection pool.
* `:connection_acquisition_wait` - Timeout to acquire a connection from pool.The total max time is this value multiplied by the number of retries.
* `connection_acquisition_retries` - Number of attempts to acquire the connection from the pool if it is overloaded. Each attempt is timed `:connection_acquisition_wait` apart.
* `:max_connections` - Maximum number of connections in the pool.
-* `:await_up_timeout` - Timeout to connect to the host.
+* `:connect_timeout` - Timeout to connect to the host.
* `:reclaim_multiplier` - Multiplied by `:max_connections` this will be the maximum number of idle connections that will be reclaimed in case the pool is overloaded.
### :pools
@@ -515,7 +516,7 @@ There are four pools used:
For each pool, the options are:
* `:size` - limit to how much requests can be concurrently executed.
-* `:timeout` - timeout while `gun` will wait for response
+* `:recv_timeout` - timeout while `gun` will wait for response
* `:max_waiting` - limit to how much requests can be waiting for others to finish, after this is reached, subsequent requests will be dropped.
## Captcha
@@ -690,9 +691,8 @@ Pleroma has the following queues:
Pleroma has these periodic job workers:
-`Pleroma.Workers.Cron.ClearOauthTokenWorker` - a job worker to cleanup expired oauth tokens.
-
-Example:
+* `Pleroma.Workers.Cron.DigestEmailsWorker` - digest emails for users with new mentions and follows
+* `Pleroma.Workers.Cron.NewUsersDigestWorker` - digest emails for admins with new registrations
```elixir
config :pleroma, Oban,
@@ -704,7 +704,8 @@ config :pleroma, Oban,
federator_outgoing: 50
],
crontab: [
- {"0 0 * * *", Pleroma.Workers.Cron.ClearOauthTokenWorker}
+ {"0 0 * * 0", Pleroma.Workers.Cron.DigestEmailsWorker},
+ {"0 0 * * *", Pleroma.Workers.Cron.NewUsersDigestWorker}
]
```
@@ -971,7 +972,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`. Interval settings sets in configuration periodic jobs [`Oban.Cron`](#obancron)
+* `clean_expired_tokens` - Enable a background job to clean expired oauth tokens. Defaults to `false`.
## Link parsing
@@ -1090,3 +1091,10 @@ config :pleroma, :frontends,
```
This would serve the frontend from the the folder at `$instance_static/frontends/pleroma/stable`. You have to copy the frontend into this folder yourself. You can choose the name and ref any way you like, but they will be used by mix tasks to automate installation in the future, the name referring to the project and the ref referring to a commit.
+
+## Ephemeral activities (Pleroma.Workers.PurgeExpiredActivity)
+
+Settings to enable and configure expiration for ephemeral activities
+
+* `:enabled` - enables ephemeral activities creation
+* `:min_lifetime` - minimum lifetime for ephemeral activities (in seconds). Default: 10 minutes.