# Generated documentation
docs/site
+docs/venv
# docker stuff
docker-db
## Fixed
- Allowed contentMap to be updated on edit
+### Changed
+- Restoring the database from a dump now goes much faster without need for work-arounds
+
### Added
- Extend the mix task `prune_objects` with option `--prune-orphaned-activities` to also prune orphaned activities, allowing to reclaim even more database space
+++ /dev/null
-all: install
- pipenv run mkdocs build
-
-install:
- pipenv install
-clean:
- rm -rf docs
You don't need to build and test the docs as long as you make sure the syntax is correct. But in case you do want to build the docs, feel free to do so.
-You'll need to install mkdocs for which you can check the [mkdocs installation guide](https://www.mkdocs.org/#installation). Generally it's best to install it using `pip`. You'll also need to install the correct dependencies.
+```sh
+# Make sure you're in the same directory as this README
+# From the root of the Akkoma repo, you'll need to do
+cd docs
-### Example using a Debian based distro
+# Optionally use a virtual environment
+python3 -m venv venv
+source venv/bin/activate
-#### 1. Install pipenv and dependencies
+# Install dependencies
+pip install -r requirements.txt
-```shell
-pip install pipenv
-pipenv sync
-```
-
-#### 2. (Optional) Activate the virtual environment
-
-Since dependencies are installed in a virtual environment, you can't use them directly. To use them you should either prefix the command with `pipenv run`, or activate the virtual environment for current shell by executing `pipenv shell` once.
-
-#### 3. Build the docs using the script
+# Run an http server who rebuilds when files change
+# Accessable on http://127.0.0.1:8000
+mkdocs serve
-```shell
-[pipenv run] make all
-```
-
-#### 4. Serve the files
+# Build the docs
+# The static html pages will have been created in the folder "site"
+# You can serve them from a server by pointing your server software (nginx, apache...) to this location
+mkdocs build
-A folder `site` containing the static html pages will have been created. You can serve them from a server by pointing your server software (nginx, apache...) to this location. During development, you can run locally with
-
-```shell
-[pipenv run] mkdocs serve
+# To get out of the virtual environment, you do
+deactivate
```
-
-This handles setting up an http server and rebuilding when files change. You can then access the docs on <http://127.0.0.1:8000>
6. Restore the database schema and akkoma role using either of the following options
* You can use the original `setup_db.psql` if you have it[²]: `sudo -Hu postgres psql -f config/setup_db.psql`.
* Or recreate the database and user yourself (replace the password with the one you find in the config file) `sudo -Hu postgres psql -c "CREATE USER akkoma WITH ENCRYPTED PASSWORD '<database-password-wich-you-can-find-in-your-config-file>'; CREATE DATABASE akkoma OWNER akkoma;"`.
-7. Now restore the Akkoma instance's data into the empty database schema[¹][³]: `sudo -Hu postgres pg_restore -d akkoma -v -1 </path/to/backup_location/akkoma.pgdump>`
-8. If you installed a newer Akkoma version, you should run `MIX_ENV=prod mix ecto.migrate`[⁴]. This task performs database migrations, if there were any.
+7. Now restore the Akkoma instance's data into the empty database schema[¹]: `sudo -Hu postgres pg_restore -d akkoma -v -1 </path/to/backup_location/akkoma.pgdump>`
+8. If you installed a newer Akkoma version, you should run `MIX_ENV=prod mix ecto.migrate`[³]. This task performs database migrations, if there were any.
9. Restart the Akkoma service.
10. Run `sudo -Hu postgres vacuumdb --all --analyze-in-stages`. This will quickly generate the statistics so that postgres can properly plan queries.
11. If setting up on a new server configure Nginx by using the `installation/akkoma.nginx` config sample or reference the Akkoma installation guide for your OS which contains the Nginx configuration instructions.
[¹]: We assume the database name and user are both "akkoma". If not, you can find the correct name in your config files.
[²]: You can recreate the `config/setup_db.psql` by running the `mix pleroma.instance gen` task again. You can ignore most of the questions, but make the database user, name, and password the same as found in your backed up config file. This will also create a new `config/generated_config.exs` file which you may delete as it is not needed.
-[³]: `pg_restore` will add data before adding indexes. The indexes are added in alphabetical order. There's one index, `activities_visibility_index` which may take a long time because it can't make use of an index that's only added later. You can significantly speed up restoration by skipping this index and add it afterwards. For that, you can do the following (we assume the akkoma.pgdump is in the directory you're running the commands):
-
-```sh
-pg_restore -l akkoma.pgdump > db.list
-
-# Comment out the step for creating activities_visibility_index by adding a semi colon at the start of the line
-sed -i -E 's/(.*activities_visibility_index.*)/;\1/' db.list
-
-# We restore the database using the db.list list-file
-sudo -Hu postgres pg_restore -L db.list -d akkoma -v -1 akkoma.pgdump
-
-# You can see the sql statement with which to create the index using
-grep -Eao 'CREATE INDEX activities_visibility_index.*' akkoma.pgdump
-
-# Then create the index manually
-# Make sure that the command to create is correct! You never know it has changed since writing this guide
-sudo -Hu postgres psql -d pleroma_ynh -c "CREATE INDEX activities_visibility_index ON public.activities USING btree (public.activity_visibility(actor, recipients, data), id DESC NULLS LAST) WHERE ((data ->> 'type'::text) = 'Create'::text);"
-```
-[⁴]: Prefix with `MIX_ENV=prod` to run it using the production config file.
+[³]: Prefix with `MIX_ENV=prod` to run it using the production config file.
## Remove
Authentication is required and the user must be an admin.
-The `/api/v1/pleroma/admin/*` path is backwards compatible with `/api/pleroma/admin/*` (`/api/pleroma/admin/*` will be deprecated in the future).
+Backwards-compatibility for admin API endpoints without version prefixes (`/api/pleroma/admin/*`) has been removed as of Akkoma 3.6.0. Please use `/api/v1/pleroma/admin/*` instead.
## `GET /api/v1/pleroma/admin/users`
Config example:
```
-config :prometheus, Pleroma.Web.Endpoint.MetricsExporter,
- enabled: true,
- auth: {:basic, "myusername", "mypassword"},
- ip_whitelist: ["127.0.0.1"],
- path: "/api/pleroma/app_metrics",
- format: :text
+config :pleroma, :instance,
+ export_prometheus_metrics: true
```
-* `enabled` (Akkoma extension) enables the endpoint
-* `ip_whitelist` (Akkoma extension) could be used to restrict access only to specified IPs
-* `auth` sets the authentication (`false` for no auth; configurable to HTTP Basic Auth, see [prometheus-plugs](https://github.com/deadtrickster/prometheus-plugs#exporting) documentation)
-* `format` sets the output format (`:text` or `:protobuf`)
-* `path` sets the path to app metrics page
-
-
-## `/api/pleroma/app_metrics`
+## `/api/v1/akkoma/metrics`
### Exports Prometheus application metrics
* Method: `GET`
-* Authentication: not required by default (see configuration options above)
+* Authentication: required
* Params: none
* Response: text
```
- job_name: 'beam'
- metrics_path: /api/pleroma/app_metrics
+ metrics_path: /api/v1/akkoma/metrics
scheme: https
static_configs:
- targets: ['otp.akkoma.dev']
--- /dev/null
+defmodule Pleroma.Repo.Migrations.RenameIndexUsersApId_COALESCEFollowerAddressIndex do
+ alias Pleroma.Repo
+
+ use Ecto.Migration
+
+ def up do
+ # By default Postgresql first restores the data and then the indexes when dumping and restoring the database.
+ # Restoring index activities_visibility_index took a very long time.
+ # users_ap_id_COALESCE_follower_address_index was later added because having this could speed up the restoration tremendously.
+ # The problem now is that restoration apparently happens in alphabetical order, so this new index wasn't created yet
+ # by the time activities_visibility_index needed it.
+ # There were several work-arounds which included more complex steps during backup/restore.
+ # By renaming this index, it should be restored first and thus activities_visibility_index can make use of it.
+ # This speeds up restoration significantly without requiring more complex or unexpected steps from people.
+ Repo.query!("ALTER INDEX public.\"users_ap_id_COALESCE_follower_address_index\"
+ RENAME TO \"aa_users_ap_id_COALESCE_follower_address_index\";")
+ end
+
+ def down do
+ Repo.query!("ALTER INDEX public.\"aa_users_ap_id_COALESCE_follower_address_index\"
+ RENAME TO \"users_ap_id_COALESCE_follower_address_index\";")
+ end
+end
Meta.allow_tag_with_these_attributes(:u, [])
Meta.allow_tag_with_these_attributes(:ul, [])
- Meta.allow_tags_with_style_attributes([:span])
-
Meta.allow_tag_with_this_attribute_values(:span, "class", [
"h-card",
"quote-inline",
projects / akkoma / commitdiff