diff --git a/debian/README.md b/debian/README.md index 893544696..800a2e090 100644 --- a/debian/README.md +++ b/debian/README.md @@ -9,6 +9,8 @@ It is recommended to see the [generic deployment guide](../deploying/generic.md) for further information if needed as usage of the Debian package is generally related. +No `apt` repository is currently offered yet, it is in the works/development. + ### Configuration When installed, the example config is placed at `/etc/conduwuit/conduwuit.toml` diff --git a/docs/deploying/docker.md b/docs/deploying/docker.md index d0aa13b37..bdbfb59c8 100644 --- a/docs/deploying/docker.md +++ b/docs/deploying/docker.md @@ -24,6 +24,9 @@ OCI images for conduwuit are available in the registries listed below. [shield-latest]: https://img.shields.io/docker/image-size/girlbossceo/conduwuit/latest [shield-main]: https://img.shields.io/docker/image-size/girlbossceo/conduwuit/main +OCI image `.tar.gz` files are also hosted directly at when uploaded by CI with a +commit hash/revision or a tagged release: + Use ```bash diff --git a/docs/deploying/generic.md b/docs/deploying/generic.md index 398ba67f6..cc50544e4 100644 --- a/docs/deploying/generic.md +++ b/docs/deploying/generic.md @@ -1,6 +1,6 @@ # Generic deployment documentation -> ## Getting help +> ### Getting help > > If you run into any problems while setting up conduwuit, ask us in > `#conduwuit:puppygock.gay` or [open an issue on @@ -8,29 +8,50 @@ ## Installing conduwuit -You may simply download the binary that fits your machine. Run `uname -m` to see -what you need. +### Static prebuilt binary + +You may simply download the binary that fits your machine architecture (x86_64 +or aarch64). Run `uname -m` to see what you need. Prebuilt fully static musl binaries can be downloaded from the latest tagged release [here](https://github.com/girlbossceo/conduwuit/releases/latest) or -`main` CI branch workflow artifact output. These also include Debian/Ubuntu packages. +`main` CI branch workflow artifact output. These also include Debian/Ubuntu +packages. + +Binaries are also available on my website directly at: + +These can be curl'd directly from. `ci-bins` are CI workflow binaries by commit +hash/revision, and `releases` are tagged releases. Sort by descending last +modified for the latest. These binaries have jemalloc and io_uring statically linked and included with them, so no additional dynamic dependencies need to be installed. +For the **best** performance; if using an `x86_64` CPU made in the last ~15 years, +we recommend using the `-haswell-` optimised binaries. This sets +`-march=haswell` which is the most compatible and highest performance with +optimised binaries. The database backend, RocksDB, most benefits from this as it +will then use hardware accelerated CRC32 hashing/checksumming which is critical +for performance. + +### Compiling + Alternatively, you may compile the binary yourself. We recommend using -Nix (or [Lix](https://lix.systems)) to build conduwuit as this has the most guaranteed -reproducibiltiy and easiest to get a build environment and output going. This also -allows easy cross-compilation. +Nix (or [Lix](https://lix.systems)) to build conduwuit as this has the most +guaranteed reproducibiltiy and easiest to get a build environment and output +going. This also allows easy cross-compilation. You can run the `nix build -L .#static-x86_64-linux-musl-all-features` or `nix build -L .#static-aarch64-linux-musl-all-features` commands based on architecture to cross-compile the necessary static binary located at -`result/bin/conduwuit`. This is reproducible with the static binaries produced in our CI. +`result/bin/conduwuit`. This is reproducible with the static binaries produced +in our CI. + +If wanting to build using standard Rust toolchains, make sure you install: +- `liburing-dev` on the compiling machine, and `liburing` on the target host +- LLVM and libclang for RocksDB -Otherwise, follow standard Rust project build guides (installing git and cloning -the repo, getting the Rust toolchain via rustup, installing LLVM toolchain + -libclang for RocksDB, installing liburing for io_uring and RocksDB, etc). +You can build conduwuit using `cargo build --release --all-features` ## Migrating from Conduit diff --git a/docs/deploying/nixos.md b/docs/deploying/nixos.md index 0372228df..3c5b0e699 100644 --- a/docs/deploying/nixos.md +++ b/docs/deploying/nixos.md @@ -29,6 +29,12 @@ conduit:Isq8FGyEC6FOXH6nD+BOeAA+bKp6X6UIbupSlGEPuOg= conduwuit:lYPVh7o1hLu1idH4Xt2QHaRa49WRGSAqzcfFd94aOTw= ``` +If needed, we have a binary cache on Cachix but it is only limited to 5GB: + +``` +https://conduwuit.cachix.org +conduwuit.cachix.org-1:MFRm6jcnfTf0jSAbmvLfhO3KBMt4px+1xaereWXp8Xg= +``` If specifying a Git remote URL in your flake, you can use any remotes that are specified on the README (the mirrors), such as the GitHub: `github:girlbossceo/conduwuit` diff --git a/docs/maintenance.md b/docs/maintenance.md index c8df95af7..378d8d4a9 100644 --- a/docs/maintenance.md +++ b/docs/maintenance.md @@ -22,23 +22,56 @@ conduwuit has moderation admin commands for: Any commands with `-list` in them will require a codeblock in the message with each object being newline delimited. An example of doing this is: -```` !admin rooms moderation ban-list-of-rooms ``` !roomid1:server.name -!roomid2:server.name !roomid3:server.name ``` ```` +```` +!admin rooms moderation ban-list-of-rooms +``` +!roomid1:server.name +!roomid2:server.name !roomid3:server.name +``` +```` -## Database +## Database (RocksDB) -If using RocksDB, there's very little you need to do. Compaction is ran -automatically based on various defined thresholds tuned for conduwuit to be high -performance with the least I/O amplifcation or overhead. Manually running -compaction is not recommended, or compaction via a timer. RocksDB is built with -io_uring support via liburing for async read I/O. +Generally there is very little you need to do. [Compaction][rocksdb-compaction] +is ran automatically based on various defined thresholds tuned for conduwuit to +be high performance with the least I/O amplifcation or overhead. Manually +running compaction is not recommended, or compaction via a timer, due to +creating unnecessary I/O amplification. RocksDB is built with io_uring support +via liburing for improved read performance. -Some RocksDB settings can be adjusted such as the compression method chosen. See -the RocksDB section in the [example config](configuration/examples.md). btrfs -users may benefit from disabling compression on RocksDB if CoW is in use. +RocksDB troubleshooting can be found [in the RocksDB section of troubleshooting](troubleshooting.md). + +### Compression -RocksDB troubleshooting can be found [in the RocksDB section of -troubleshooting](troubleshooting.md). +Some RocksDB settings can be adjusted such as the compression method chosen. See +the RocksDB section in the [example config](configuration/examples.md). + +btrfs users have reported that database compression does not need to be disabled +on conduwuit as the filesystem already does not attempt to compress. This can be +validated by using `filefrag -v` on a `.SST` file in your database, and ensure +the `physical_offset` matches (no filesystem compression). It is very important +to ensure no additional filesystem compression takes place as this can render +unbuffered Direct IO inoperable, significantly slowing down read and write +performance. See + +> Compression is done using the COW mechanism so it’s incompatible with +> nodatacow. Direct IO read works on compressed files but will fall back to +> buffered writes and leads to no compression even if force compression is set. +> Currently nodatasum and compression don’t work together. + +### Files in database + +Do not touch any of the files in the database directory. This must be said due +to users being mislead by the `.log` files in the RocksDB directory, thinking +they're server logs or database logs, however they are critical RocksDB files +related to WAL tracking. + +The only safe files that can be deleted are the `LOG` files (all caps). These +are the real RocksDB telemetry/log files, however conduwuit has already +configured to only store up to 3 RocksDB `LOG` files due to generall being +useless for average users unless troubleshooting something low-level. If you +would like to store nearly none at all, see the `rocksdb_max_log_files` +config option. ## Backups @@ -95,3 +128,5 @@ Built-in S3 support is also planned, but for now using a "S3 filesystem" on `media/` works. conduwuit also sends a `Cache-Control` header of 1 year and immutable for all media requests (download and thumbnail) to reduce unnecessary media requests from browsers, reduce bandwidth usage, and reduce load. + +[rocksdb-compaction]: https://github.com/facebook/rocksdb/wiki/Compaction diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index 283cdeeed..d25c97621 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -91,16 +91,6 @@ reliability at a slight performance cost due to TCP overhead. ## RocksDB / database issues -#### Direct IO - -Some filesystems may not like RocksDB using [Direct -IO](https://github.com/facebook/rocksdb/wiki/Direct-IO). Direct IO is for -non-buffered I/O which improves conduwuit performance and reduces system CPU -usage, but at least FUSE and possibly ZFS are filesystems potentially known -to not like this. See the [example config](configuration/examples.md) for -disabling it if needed. Issues from Direct IO on unsupported filesystems are -usually shown as startup errors. - #### Database corruption If your database is corrupted *and* is failing to start (e.g. checksum