forked from AkkomaGang/akkoma
Docs: More formatting and typo correction
This commit is contained in:
solidsanek
parent
5705569bc3
commit
5f9c28c8fa
7 changed files with 49 additions and 49 deletions
|
|
@ -35,7 +35,7 @@ To add configuration to your config file, you can copy it from the base config.
|
|||
* `allow_relay`: Permits remote instances to subscribe to all public posts of your instance. This may increase the visibility of your instance.
|
||||
* `public`: Allows unauthenticated access to public resources on your instance. This is essentially used as the default value for `:restrict_unauthenticated`.
|
||||
See `restrict_unauthenticated` for more details.
|
||||
* `quarantined_instances`: *DEPRECATED* ActivityPub instances where activities will not be sent. They can still reach there via other means; we just won't send them.
|
||||
* `quarantined_instances`: *DEPRECATED* ActivityPub instances where activities will not be sent. They can still reach them via other means; we just won't send them.
|
||||
* `allowed_post_formats`: MIME-type list of formats allowed to be posted (transformed into HTML).
|
||||
* `extended_nickname_format`: Set to `true` to use extended local nicknames format (allows underscores/dashes). This will break federation with older software for these nicknames.
|
||||
* `max_pinned_statuses`: The maximum number of pinned statuses. `0` will disable the feature.
|
||||
|
|
@ -79,7 +79,7 @@ To add configuration to your config file, you can copy it from the base config.
|
|||
* `enabled`: Enables to send a welcome email to a newly registered user. Defaults to `false`.
|
||||
* `sender`: The email address or tuple with `{nickname, email}` that will use as sender to the welcome email.
|
||||
* `subject`: A subject of welcome email.
|
||||
* `html`: A HTML that will be sent to a newly registered users as an email.
|
||||
* `html`: HTML that will be sent to a newly registered users as an email.
|
||||
* `text`: A text that will be sent to a newly registered users as an email.
|
||||
|
||||
Example:
|
||||
|
|
@ -360,7 +360,7 @@ This section describes PWA manifest instance-specific values. Currently, this op
|
|||
* `whitelist`: List of hosts with scheme to bypass the media proxy (e.g. `https://example.com`)
|
||||
* `invalidation`: options for remove media from cache after delete object:
|
||||
* `enabled`: Enables purge cache
|
||||
* `provider`: Which one of the [purge cache strategy](#purge-cache-strategy) to use.
|
||||
* `provider`: Which one of the [purge cache strategies](#purge-cache-strategy) to use.
|
||||
|
||||
## :media_preview_proxy
|
||||
|
||||
|
|
@ -374,7 +374,7 @@ This section describes PWA manifest instance-specific values. Currently, this op
|
|||
|
||||
#### Pleroma.Web.MediaProxy.Invalidation.Script
|
||||
|
||||
This strategy allows to perform external shell script to purge cache.
|
||||
This strategy allows performing an external shell script to purge cache.
|
||||
URLs of attachments are passed to the script as arguments.
|
||||
|
||||
* `script_path`: Path to the external script.
|
||||
|
|
@ -389,7 +389,7 @@ config :pleroma, Pleroma.Web.MediaProxy.Invalidation.Script,
|
|||
|
||||
#### Pleroma.Web.MediaProxy.Invalidation.Http
|
||||
|
||||
This strategy allows to perform custom HTTP request to purge cache.
|
||||
This strategy allows performing a custom HTTP request to purge cache.
|
||||
|
||||
* `method`: HTTP method. Default is `purge`
|
||||
* `headers`: HTTP headers.
|
||||
|
|
@ -425,7 +425,7 @@ config :pleroma, Pleroma.Web.MediaProxy.Invalidation.Http,
|
|||
!!! note
|
||||
`Phoenix` endpoint configuration, all configuration options can be viewed [here](https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#module-dynamic-configuration), only common options are listed here.
|
||||
|
||||
* `http` - a list containing HTTP protocol configuration, all configuration options can be viewed [here](https://hexdocs.pm/plug_cowboy/Plug.Cowboy.html#module-options), only common options are listed here. For deployment using docker, you need to set this to `[ip: {0,0,0,0}, port: 4000]` to make Akkoma accessible from other containers (such as your NGINX server).
|
||||
* `http` - a list containing HTTP protocol configuration, all configuration options can be viewed [here](https://hexdocs.pm/plug_cowboy/Plug.Cowboy.html#module-options), only common options are listed here. For deployment using Docker, you need to set this to `[ip: {0,0,0,0}, port: 4000]` to make Akkoma accessible from other containers (such as your NGINX server).
|
||||
- `ip` - a tuple consisting of 4 integers
|
||||
- `port`
|
||||
* `url` - a list containing the configuration for generating URLs, accepts
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ This guide will assume that you have administrative rights, either as root or a
|
|||
|
||||
* `nginx` (preferred, example configs for other reverse proxies can be found in the repo)
|
||||
* `certbot` (or any other ACME client for Let’s Encrypt certificates)
|
||||
* `imagemagic`
|
||||
* `imagemagick`
|
||||
* `ffmpeg`
|
||||
* `exiftool`
|
||||
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ sudo apt install imagemagick ffmpeg libimage-exiftool-perl
|
|||
|
||||
### Install Akkoma-be
|
||||
|
||||
* Log into the `akkoma` user and clone the AkkomaBE repository from the stable branch and make the Akkoma user the owner of the directory:
|
||||
* Log into the `akkoma` user and clone the Akkoma-be repository from the stable branch and make the Akkoma user the owner of the directory:
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /opt/akkoma
|
||||
|
|
|
|||
|
|
@ -2,17 +2,17 @@
|
|||
|
||||
## Installation
|
||||
|
||||
This guide will show you how to get Akkoma working in a docker container,
|
||||
This guide will show you how to get Akkoma working in a Docker container,
|
||||
if you want isolation, or if you run a distribution not supported by the OTP
|
||||
releases.
|
||||
|
||||
If you want to migrate from or OTP to docker, check out [the migration guide](./migrating_to_docker_en.md).
|
||||
If you want to migrate from or OTP to Docker, check out [the migration guide](./migrating_to_docker_en.md).
|
||||
|
||||
### Prepare the system
|
||||
|
||||
* Install docker and docker compose
|
||||
* Install Docker and Docker Compose
|
||||
* [Docker](https://docs.docker.com/engine/install/)
|
||||
* [Docker-compose](https://docs.docker.com/compose/install/)
|
||||
* [Docker Compose](https://docs.docker.com/compose/install/)
|
||||
* This will usually just be a repository installation and a package manager invocation.
|
||||
* Clone the Akkoma repository
|
||||
* `git clone https://akkoma.dev/AkkomaGang/akkoma.git -b stable`
|
||||
|
|
@ -26,7 +26,7 @@ echo "DOCKER_USER=$(id -u):$(id -g)" >> .env
|
|||
```
|
||||
|
||||
This probably won't need to be changed, it's only there to set basic environment
|
||||
variables for the docker compose file.
|
||||
variables for the Docker Compose file.
|
||||
|
||||
### Building the container
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ and debugging if required.
|
|||
```
|
||||
|
||||
This will generate a container called `akkoma` which we can use
|
||||
in our compose environment.
|
||||
in our Compose environment.
|
||||
|
||||
### Generating your instance
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ docker compose up
|
|||
|
||||
If everything went well, you should be able to access your instance at http://localhost:4000
|
||||
|
||||
You can `ctrl-c` out of the docker compose now to shutdown the server.
|
||||
You can `ctrl-c` out of the Docker Compose now to shutdown the server.
|
||||
|
||||
### Running in the background
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ And follow the prompts
|
|||
|
||||
### Reverse proxies
|
||||
|
||||
This is a tad more complex in docker than on the host itself. It
|
||||
This is a tad more complex in Docker than on the host itself. It
|
||||
|
||||
You've got two options.
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ cp docker-resources/Caddyfile.example docker-resources/Caddyfile
|
|||
|
||||
Then edit the TLD in your caddyfile to the domain you're serving on.
|
||||
|
||||
Uncomment the `caddy` section in the docker compose file,
|
||||
Uncomment the `caddy` section in the Docker Compose file,
|
||||
then run `docker compose up -d` again.
|
||||
|
||||
#### Running a reverse proxy on the host
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Migrating to a Docker Installation
|
||||
|
||||
If you for any reason wish to migrate a source or OTP install to a docker one,
|
||||
If you for any reason wish to migrate a source or OTP install to a Docker one,
|
||||
this guide is for you.
|
||||
|
||||
You have a few options - your major one will be whether you want to keep your
|
||||
|
|
@ -10,9 +10,9 @@ You probably should, in the first instance.
|
|||
|
||||
### Prepare the system
|
||||
|
||||
* Install docker and docker compose
|
||||
* Install Docker and Docker Compose
|
||||
* [Docker](https://docs.docker.com/engine/install/)
|
||||
* [Docker-compose](https://docs.docker.com/compose/install/)
|
||||
* [Docker Compose](https://docs.docker.com/compose/install/)
|
||||
* This will usually just be a repository installation and a package manager invocation.
|
||||
|
||||
=== "Source"
|
||||
|
|
@ -21,7 +21,7 @@ git pull
|
|||
```
|
||||
|
||||
=== "OTP"
|
||||
Clone the akkoma repository
|
||||
Clone the `akkoma` repository
|
||||
|
||||
```bash
|
||||
git clone https://akkoma.dev/AkkomaGang/akkoma.git -b stable
|
||||
|
|
@ -39,14 +39,14 @@ pg_dump -d akkoma_prod --format c > akkoma_backup.sql
|
|||
### Getting your static files in the right place
|
||||
|
||||
This will vary by every installation. Copy your `instance` directory to `instance/` in
|
||||
the akkoma source directory - this is where the docker container will look for it.
|
||||
the Akkoma source directory - this is where the Docker container will look for it.
|
||||
|
||||
For *most* from-source installs it'll already be there.
|
||||
|
||||
And the same with `uploads`, make sure your uploads (if you have them on disk) are
|
||||
located at `uploads/` in the akkoma source directory.
|
||||
located at `uploads/` in the Akkoma source directory.
|
||||
|
||||
If you have them on a different disk, you will need to mount that disk into the docker compose file,
|
||||
If you have them on a different disk, you will need to mount that disk into the Docker Compose file,
|
||||
with an entry that looks like this:
|
||||
|
||||
```yaml
|
||||
|
|
@ -66,7 +66,7 @@ echo "DOCKER_USER=$(id -u):$(id -g)" >> .env
|
|||
```
|
||||
|
||||
This probably won't need to be changed, it's only there to set basic environment
|
||||
variables for the docker compose file.
|
||||
variables for the Docker Compose file.
|
||||
|
||||
=== "From source"
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ config :pleroma, Pleroma.Repo,
|
|||
|
||||
### Building the container
|
||||
|
||||
The container provided is a thin wrapper around akkoma's dependencies,
|
||||
The container provided is a thin wrapper around Akkoma's dependencies,
|
||||
it does not contain the code itself. This is to allow for easy updates
|
||||
and debugging if required.
|
||||
|
||||
|
|
@ -105,9 +105,9 @@ and debugging if required.
|
|||
```
|
||||
|
||||
This will generate a container called `akkoma` which we can use
|
||||
in our compose environment.
|
||||
in our Compose environment.
|
||||
|
||||
### Setting up the docker resources
|
||||
### Setting up the Docker resources
|
||||
|
||||
```bash
|
||||
# These won't exist if you're migrating from OTP
|
||||
|
|
@ -133,9 +133,9 @@ docker compose run --rm akkoma pg_restore -v -U akkoma -j $(grep -c ^processor /
|
|||
### Reverse proxies
|
||||
|
||||
If you're just reusing your old proxy, you may have to uncomment the line in
|
||||
the docker compose file under `ports`. You'll find it.
|
||||
the Docker Compose file under `ports`. You'll find it.
|
||||
|
||||
Otherwise, you can use the same setup as the [docker installation guide](./docker_en.md#reverse-proxies).
|
||||
Otherwise, you can use the same setup as the [Docker installation guide](./docker_en.md#reverse-proxies).
|
||||
|
||||
### Let's go
|
||||
|
||||
|
|
@ -143,11 +143,11 @@ Otherwise, you can use the same setup as the [docker installation guide](./docke
|
|||
docker compose up -d
|
||||
```
|
||||
|
||||
You should now be at the same point as you were before, but with a docker install.
|
||||
You should now be at the same point as you were before, but with a Docker install.
|
||||
|
||||
{! installation/frontends.include !}
|
||||
|
||||
See the [docker installation guide](./docker_en.md) for more information on how to
|
||||
See the [Docker installation guide](./docker_en.md) for more information on how to
|
||||
update.
|
||||
|
||||
#### Further reading
|
||||
|
|
|
|||
|
|
@ -33,13 +33,13 @@ support.
|
|||
|
||||
Other than things bundled in the OTP release, Akkoma depends on:
|
||||
|
||||
* curl (to download the release build)
|
||||
* unzip (needed to unpack release builds)
|
||||
* ncurses (ERTS won't run without it)
|
||||
* postgresql (also utilizes extensions in postgresql-contrib)
|
||||
* nginx (could be swapped with another reverse proxy, but this guide covers only it)
|
||||
* certbot (for Let's Encrypt certificates, could be swapped with another ACME client, but this guide covers only it)
|
||||
* libmagic/file
|
||||
* `curl` (to download the release build)
|
||||
* `unzip` (needed to unpack release builds)
|
||||
* `ncurses` (ERTS won't run without it)
|
||||
* `postgresql` (also utilizes extensions in postgresql-contrib)
|
||||
* `nginx` (could be swapped with another reverse proxy, but this guide covers only it)
|
||||
* `certbot` (for Let's Encrypt certificates, could be swapped with another ACME client, but this guide covers only it)
|
||||
* `libmagic`/`file`
|
||||
|
||||
=== "Alpine"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -72,12 +72,12 @@ Please note that running your own OTP release has some minor caveats that you sh
|
|||
|
||||
Other than things bundled in the OTP release, Akkoma depends on:
|
||||
|
||||
* curl (to download the release build)
|
||||
* ncurses (ERTS won't run without it)
|
||||
* postgresql (also utilizes extensions in postgresql-contrib)
|
||||
* nginx (could be swapped with another reverse proxy, but this guide covers only it)
|
||||
* certbot (for Let's Encrypt certificates, could be swapped with another ACME client, but this guide covers only it)
|
||||
* libmagic/file
|
||||
* `curl` (to download the release build)
|
||||
* `ncurses` (ERTS won't run without it)
|
||||
* `postgresql` (also utilizes extensions in `postgresql-contrib`)
|
||||
* `nginx` (could be swapped with another reverse proxy, but this guide covers only it)
|
||||
* `certbot` (for Let's Encrypt certificates, could be swapped with another ACME client, but this guide covers only it)
|
||||
* `libmagic`/`file`
|
||||
|
||||
First, update your system, if not already done:
|
||||
|
||||
|
|
@ -260,7 +260,7 @@ There are some things to take note of when you are running your own OTP builds.
|
|||
|
||||
Using your custom OTP build, you will not be able to update the installation using the `pleroma_ctl update` command. Running this command would overwrite your install with an OTP release from the main Akkoma repository, which will break your install.
|
||||
|
||||
Instead, you will have to rebuild your OTP release every time there are updates, then manually move it to where your Akkoma installation is running, overwriting the old OTP release files. Make sure to stop the Akkoma-BE server before overwriting any files!
|
||||
Instead, you will have to rebuild your OTP release every time there are updates, then manually move it to where your Akkoma installation is running, overwriting the old OTP release files. Make sure to stop the Akkoma-be server before overwriting any files!
|
||||
|
||||
After that, run the `pleroma_ctl migrate` command as usual to perform database migrations.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue