Adding last 3 posts from rtd.ditatompel.com #1

This commit is contained in:
Cristian Ditaputratama 2023-05-31 09:52:38 +07:00
parent 62718944e5
commit bbe2641dda
Signed by: ditatompel
GPG key ID: 31D3D06D77950979
19 changed files with 584 additions and 0 deletions

View file

@ -0,0 +1,182 @@
---
title: "How to install Misskey in Ubuntu 22.04 (Manual without Docker)"
description: "Step-by-step installing Misskey, an open-source social media platform that has been making waves in the world of fediverse enthusiasts"
# linkTitle:
date: 2023-02-24T08:51:58+07:00
lastmod:
draft: false
noindex: false
# comments: false
nav_weight: 1000
# nav_icon:
# vendor: bootstrap
# name: toggles
# color: '#e24d0e'
series:
# - Tutorial
categories:
- Self-Hosted
- SysAdmin
tags:
- Misskey
- NodeJS
- NVM
- PM2
- PostgreSQL
images:
# menu:
# main:
# weight: 100
# params:
# icon:
# vendor: bs
# name: book
# color: '#e24d0e'
authors:
- ditatompel
---
**Misskey** is an *open-source* social media platform that has been making waves in the world of *fediverse* enthusiasts. As someone who has *recently* discovered Misskey, I can confidently say that it has quickly become my favorite social media platform. From its customizable interface to its community-driven approach, Misskey offers a unique and refreshing experience for users.
<!--more-->
In this article, I want to share my experience **installing Misskey**. There are several ways to create / deploy Misskey instance, from using Docker to manually install all required dependencies. In tis article I choose to use manual installation method.
## Why use the manual installation method, when there is an easier way using docker?
1. **Overhead**. Because **running a containerized app inside a containerized operating system can create additional layers of abstraction, which can lead to increased overhead and reduced performance**. This is because each layer adds a small amount of overhead, and the more layers you have, the more overhead you will incur.
2. I **want to run multiple Misskey instance under one linux container**. Imagine if I run 5 instances and in the same time I should install and run containerized NodeJS and PostgreSQL for each instance.
While running containerized apps inside a containerized operating system can be a convenient way to manage applications, it may not always be the most optimal approach from a performance perspective.
## Requirements
- **NodeJS** `18.13.x` (we will use **NVM** for this)
- **PostgreSQL** `15.x`
- **Redis**
- **FFmpeg**
- **PM2** (optional)
### Install PostgreSQL 15
**PostgreSQL 15 is not available in official Ubuntu 22.04**, you need to enable it's official repository from PostgreSQL itself.
```shell
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget -qO- https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo tee /etc/apt/trusted.gpg.d/pgdg.asc &>/dev/null
sudo apt update
sudo apt install postgresql postgresql-client -y
```
Don't forget to start PostgreSQL and make it run on **system startup**.
```shell
sudo systemctl status postgresql
sudo systemctl enable postgresql
```
### Install Redis and FFmpeg
Simply run :
```shell
sudo apt install redis ffmpeg
```
make sure to start Redis and make it run on system startup.
```shell
sudo systemctl start redis-server.service
sudo systemctl enable redis-server.service
```
### Install NodeJS 18 using NVM
> _Install NVM and nodeJS as regular user. **Running commands below as root is not recommended!**_
Download and run NVM install script:
```shell
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
```
When the script is executed, it clones the nvm repository to `~/.nvm`, and attempts to add the `source` lines your profile file (`~/.bash_profile`, `~/.zshrc`, `~/.profile`, or `~/.bashrc`).
Relogin to your server so you can use `nvm` command.
Install required NodeJS version, in this article we need to use NodeJS 18.
```shell
nvm install 18
```
You also need to enable `corepack` :
```shell
npm install -g corepack
corepack enable
```
### Install and build Misskey
Clone the Misskey repository
```shell
git clone --recursive https://github.com/misskey-dev/misskey.git
```
Navigate to the repository, and check out the latest version of Misskey:
```shell
cd misskey
git checkout master
```
Download submodules and install Misskey's dependencies.
```shell
git submodule update --init
pnpm install --frozen-lockfile
```
Run this following command to build misskey. (`python` is required).
```shell
NODE_ENV=production pnpm run build
```
### Configure Misskey
You need to create the appropriate PostgreSQL users with respective passwords, and an empty database for Misskey. The encoding of the database should be `UTF-8`.
```shell
sudo -u postgres psql
```
```sql
CREATE DATABASE <your_db_name> WITH ENCODING = 'UTF8';
CREATE USER <your_misskey_db_user> WITH ENCRYPTED PASSWORD '<YOUR_PASSWORD>';
GRANT ALL PRIVILEGES ON DATABASE <your_db_name> TO <your_misskey_db_user>;
GRANT ALL ON SCHEMA public TO <your_misskey_db_user>;
\q
```
> _**IMPORTANT**: In PostgreSQL 15, a fundamental change took place which is relevant to every user who happens to work with permissions: The default permissions of the public schema have been modified._
> _The `GRANT ALL ON SCHEMA public TO ...` is needed, otherwise you'll find : `ERROR: permission denied for schema public` message when running database initialisation._
After that, copy `.config/example.yml` to `.config/default.yml` under your Misskey repository.
Edit `.config/default.yml` to fit with your need and environment.
Finally, run the database initialisation:
```shell
pnpm run init
```
## Auto start Misskey
Last, but not least, we need to start Misskey when the system start. You can [auto start Misskey with systemd as described on it's official documentation](https://misskey-hub.net/en/docs/install/manual.html#launch-with-systemd).
### Using PM2 to manage Misskey
Because I love to use PM2 as my NodeJS application manager, I'll use that instead of `systemd`. To install PM2:
```shell
npm install pm2 -g
```
To auto run PM2 at startup as your current user, run **pm2 startup** and follow the output insruction.
Then to run Misskey using PM2:
```shell
pm2 start "NODE_ENV=production pnpm run start" --name <your_process_name>
```
Dont forget to save managed process by PM2 using `pm2 save` command.
## Updating Misskey
To update Misskey that run using NodeJS (via NPM and PM2), you can follow my another article: [Misskey NodeJS (NVM with PM2) update steps]({{< ref "/tutorials/misskey-nodejs-nvm-with-pm2-update-steps/index.md" >}}).
That's it, and welcome to another awesome Fediverse project! Take a look my Fediverse account [@ditatompel@hey.ditatompel.com](https://hey.ditatompel.com/@ditatompel) from Misskey.
## Resources
- [Misskey-hub.net :official installation page](https://misskey-hub.net/en/docs/install/manual.html)
- [linuxtechi.com: How to Install PostgreSQL 15 on Ubuntu 22.04 Step-by-Step](https://www.linuxtechi.com/how-to-install-postgresql-on-ubuntu/)
- [cybertec-postgresql.com: PostgreSQL ERROR: PERMISSION DENIED FOR SCHEMA PUBLIC](https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public/)

Binary file not shown.

After

Width:  |  Height:  |  Size: 124 KiB

View file

@ -0,0 +1,96 @@
---
title: "Misskey NodeJS (NVM with PM2) update steps"
description: "Misskey is under heavy development and event minor update need higher version of NodeJS. In this article, I want to share my experience how to perform an update to Misskey instances which run using PM2 and NVM"
# linkTitle:
date: 2023-05-20T08:52:58+07:00
lastmod:
draft: false
noindex: false
# comments: false
nav_weight: 1000
# nav_icon:
# vendor: bootstrap
# name: toggles
# color: '#e24d0e'
series:
# - Tutorial
categories:
- SysAdmin
- Self-Hosted
tags:
- Misskey
- NodeJS
- NVM
- PM2
images:
# menu:
# main:
# weight: 100
# params:
# icon:
# vendor: bs
# name: book
# color: '#e24d0e'
authors:
- ditatompel
---
If you following my article about [How to install Misskey in Ubuntu 22.04 (Manual NodeJS and PM2 without Docker)]({{< ref "/tutorials/how-to-install-misskey-in-ubuntu-22-04-manual-without-docker/index.md" >}}), you may encounter some problem when trying to [update your Misskey instances](https://misskey-hub.net/en/docs/install/manual.htmlhow-to-update-your-misskey-server-to-the-latest-version).
<!--more-->
This because **Misskey** is under heavy development and event *minor* update need higher version of **NodeJS**. For example, **Misskey** `13.10.3` was released in March, 25th and it works well with **NodeJS** `18.15`. Last week (May, 12th), *Misskey* `13.12.2` was released and need to be run using (at least) on **NodeJS** `18.16`. In this article, I want to share my experience how to perform an update to **Misskey instances**.
## Install / update required dependencies for new version
First you need to know what is the [minimum requirement (dependencies)](https://misskey-hub.net/en/docs/install/manual.html#dependencies) for the latest *stable* version of **Misskey**, especially for **NodeJS** version and **PostgreSQL**. I'll take example of upgrading **Misskey** from `13.10.3` to `13.12.2` which have different minimum requirement of **NodeJS** version.
### NodeJS
```shell
nvm install 18.16
use 18.16
```
Install `corepack` and enable it from your new **nodeJS** version environment:
```shell
npm install -g corepack
corepack enable
```
### PM2
If you see _"In-memory **PM2** is out-of-date"_ message from *pm2* You may want to update your `pm2` package (optional):
1. Stop and delete all your current **pm2** process (see the processes with `pm2 ps` command):
```shell
pm2 delete nameOfProcess
```
2. If you using `systemd` to start the **pm2** process, **unstartup** it with `pm2 unstartup systemd` and execute the output from your shell.
```shell
pm2 unstartup systemd
```
3. Update and **re-enable pm2** process:
```shell
pm2 update
pm2 startup
```
Don't forget to execute the output of `pm2 startup` command.
## Update Misskey
After all required dependencies is installed, update the **Misskey** app itself. Navigate to your Misskey installation directory and execute these commands:
```shell
git checkout master
git pull
git submodule update --init
NODE_ENV=production pnpm install --frozen-lockfile
NODE_ENV=production pnpm run build
pnpm run migrate
```
Then re-run Misskey using PM2:
```shell
pm2 start "NODE_ENV=production pnpm run start" --name <your_process_name>
```
If you encounter any problems with updating, try to run `pnpm run clean-all` command and **retry the Misskey update process**.

Binary file not shown.

After

Width:  |  Height:  |  Size: 113 KiB

View file

@ -0,0 +1,150 @@
---
title: "Menyelamatkan ASCIINEMA SERVER Yang Gagal Upgrade Karena PostgreSQL"
description: "Cara menangani ASCIINEMA server yang gagal upgrade karena PostgreSQL dengan melakukan backup dan recovery data yang lama."
# linkTitle:
date: 2023-03-11T08:52:39+07:00
lastmod:
draft: false
noindex: false
# comments: false
nav_weight: 1000
# nav_icon:
# vendor: bootstrap
# name: toggles
# color: '#e24d0e'
series:
# - Tutorial
categories:
- SysAdmin
- Self-Hosted
tags:
- asciinema
- PostgreSQL
- Docker
images:
# menu:
# main:
# weight: 100
# params:
# icon:
# vendor: bs
# name: book
# color: '#e24d0e'
authors:
- ditatompel
---
Hari ini, saya menemui kendala saat melakukan upgrade [self-hosted asciinema-server](https://asciinema.ditatompel.com/) milik saya. Setelah [mengikuti proses upgrade sesuai dokumentasi asciinema-server di GitHub](https://github.com/asciinema/asciinema-server/wiki/Installation-guide#upgrading), *container* `phoenix` dan `postgres` gagal berjalan dan selalu restart.
<!--more-->
saya mencoba mencari informasi apa yang menyebabkan hal tersebut terjadi. Dari log *container* `phoenix`, saya mendapati *error* berikut :
> **(DBConnection.ConnectionError)** _connection not available and request was dropped from queue after xxxxms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:_
>
> *By tracking down slow queries and making sure they are running fast enough*
> *Increasing the pool_size (albeit it increases resource consumption)*
> *Allow requests to wait longer by increasing :queue_target and :queue_interval*
> *See DBConnection.start_link/2 for more information*
kemudian dari log **postgreSQL** *container* itu sendiri, saya mendapatkan *error log* yang kurang lebih menginformasikan bahwa file yang berada di volume `postgresql` *container* tidak kompatible dengan yang sedang berjalan.:
> **FATAL**: database files are incompatible with server
> **DETAIL**: The data directory was initialized by PostgreSQL version 12, which is not compatible with this version 14
Dari informasi error yang saya dapatkan tersebut, saya memutuskan untuk:
1. Melakukan *downgrade* sementara supaya saya bisa melakukan **backup database** yang sebelumnya.
2. Menghapus dan **menginstall kembali PostgreSQL yang sesuai dengan versi repositori masternya**.
3. Melakukan **restore database** yang telah saya backup dan berharap proses restore dapat berjalan dengan lancar.
Dan **ternyata berhasil**!
## Proses penyelamatan
Masuk ke direktori `asciinema-server`, dan hentikan semua container yang berkaitan dengan **asciinema-server** dengan menjalankan perintah `docker-compose down`.
Download `asciinema-server` *docker image* yang terbaru:
```bash
docker pull asciinema/asciinema-server
```
Download *config* asciinema dari *upstream* dan lakukan *merge* ke *branch* milik Anda (jika belum dilakukan):
```bash
git fetch origin
git merge origin/master
# Perintah dibawah optional, tergantung dengan cara installasi awal asciinema-server Anda
git stash
git stash pop
git add .
git commit -m "Local upgrade"
git merge origin/master
```
### Downgrade PostgreSQL dan lakukan backup
Setelah itu, edit `docker-compose.yml`. Kembalikan `postgresql` image dari versi `14` ke versi sebelumnya (di kasus saya, versi sebelumnya di versi `12`).
```yml
version: '2'
services:
postgres:
image: postgres:12-alpine
container_name: asciinema_postgres
### bla bla bla
```
Hal ini perlu dilakukan supaya kita dapat melakukan *dump database* PostgreSQL.
**Nyalakan PostgreSQL**, tapi **biarkan service asciinema-server lainnya tetap mati**.
```bash
docker-compose up -d postgres
```
Lakukan backup dengan menjalankan perintah berikut:
```bash
docker exec -it <DOCKER_CONTAINER_ID> pg_dump postgres -U postgres > asciinemadump.sql
```
> **Catatan**: informasi `DOCKER_CONTAINER_ID` bisa didapatkan dari perintah `docker ps`.
Setelah proses *dump database* selesai, matikan container postgresql tersebut dengan menjalankan perintah:
```bash
docker-compose down
```
**Hapus semua volume data yang digunakan oleh container postgresql yang lama** (defaultnya `./volumes/postgres`). Sebaiknya anda melakukan **backup** direktori tersebut dengan cara memindahkan ke folder lain sebelum menghapusya secara permanen.
### Jalankan PostgreSQL versi upstream
Setelah itu, hapus *docker volume* untuk `PostgreSQL 12` dan **gunakan PostgreSQL sesuai dengan versi dari upstream** (`v14`).
Edit kembali `docker-compose.yml` dan kembalikan sesuai dengan versi upstream.
```yml
version: '2'
services:
postgres:
image: postgres:14-alpine
container_name: asciinema_postgres
### bla bla bla
```
Nyalakan `PostgreSQL 14`, tapi **tetap biarkan service asciinema-server lainnya tetap mati** dulu.
```bash
docker-compose up -d postgres
```
### Restore PostgreSQL backup
Setelah PostgreSQL yang sesuai dengan versi upstream berjalan, lakukan proses *restore database* yang sudah kita backup sebelumnya.
Copy file `asciinemadump.sql` ke *volume postgres* (`./volumes/postgres`) dan ubah *file permission* supaya user `root` **didalam container** dapat membaca file tersebut.
Kemudian jalankan perintah berikut untuk melakukan **restore database** :
```bash
docker exec -it <DOCKER_CONTAINER_ID> psql -d postgres -U postgres -f /var/lib/postgresql/data/asciinemadump.sql
```
> **Catatan**: `DOCKER_CONTAINER_ID` Anda akan berbeda dengan `DOCKER_CONTAINER_ID` yang sebelumnya. Pastikan gunakan *docker container ID* yang benar.
### Jalankan asciinema-server seperti biasa
Setelah itu, jalankan semua service asciinema-server seperti biasa dengan menjalankan perintah `docker-compose up -d`. Seharusnya Anda sudah dapat menggakses **self-hosted asciinema-server** Anda kembali.

View file

@ -0,0 +1,156 @@
---
title: "Rescue broken asciinema-server upgrade (PostgreSQL 12 => 14)"
description: "How to rescue broken asciinema-server upgrade that caused by incompatible files in the volume of the old PostgreSQL 12 container with the latest upstream version"
# linkTitle:
date: 2023-03-11T08:52:39+07:00
lastmod:
draft: false
noindex: false
# comments: false
nav_weight: 1000
# nav_icon:
# vendor: bootstrap
# name: toggles
# color: '#e24d0e'
series:
# - Tutorial
categories:
- SysAdmin
- Self-Hosted
tags:
- asciinema
- PostgreSQL
- Docker
images:
# menu:
# main:
# weight: 100
# params:
# icon:
# vendor: bs
# name: book
# color: '#e24d0e'
authors:
- ditatompel
---
Today, I'm experiencing some problem with my recent [self-hosted asciinema-server](https://asciinema.ditatompel.com/) upgrade. After following the upgrade process according to the [asciinema-server documentation page on GitHub](https://github.com/asciinema/asciinema-server/wiki/Installation-guide), the `phoenix` and `postgresql` containers failed to run and kept restarting.
<!--more-->
I'm trying to find information on what causes this to happen. From the *container* log, I got the following error:
> _**(DBConnection. ConnectionError)** connection not available and request was dropped from queue after xxxxms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by:_
```plain
By tracking down slow queries and making sure they are running fast enough
Increasing the pool_size (albeit it increases resource consumption)
Allow requests to wait longer by increasing :queue_target and :queue_interval
See DBConnection. start_link/2 for more information
```
Then from the log of the posgreSQL container itself, I found information that **the files in the volume of the PostgreSQL container are not compatible with the one that currently running** :
> _**FATAL**: database files are incompatible with server_
> _**DETAIL**: The data directory was initialized by PostgreSQL version 12, which is not compatible with this version 14_
So, the root cause likely due database upgrade **from PostgreSQL 12 to PostgreSQL 14**.
From these informations, I decided to:
1. Doing a temporary downgrade so I can back up the previous database.
2. Uninstall and **reinstall** the appropriate version of PostgreSQL from the **master repository**.
3. Restore the database that I have backed up and **hope** that the restore process can run smoothly.
**And it worked!**
## Rescue process
Before begining, I assume that you follow the official installation process.
Enter the `asciinema-server` directory, and **stop all containers** associated with `asciinema-server` by running `docker-compose down`.
Download the latest `asciinema-server` docker image:
```shell
docker pull asciinema/asciinema-server
```
Download the **asciinema** config from *upstream* and **merge it into your branch** (if you haven't already):
```shell
git fetch origin
git merge origin/master
# The commands below are optional
# and depending on your initial asciinema-server installation
git stash
git stash pop
git add .
git commit -m "Local upgrade"
git merge origin/master
```
### 1. Downgrade PostgreSQL to previous running version and back up the old data
After that, edit `docker-compose.yml`, **temporarily** revert **postgres image** from version `14` to your previous version (for me, my previous version was at version `12`).
```yaml
version: '2'
services:
postgres:
image: postgres:12-alpine
container_name: asciinema_postgres
### blah blah blah
```
This is necessary so that we can **dump** the PostgreSQL database.
Turn on PostgreSQL, but **leave the other `asciinema-server` services off**.
```shell
docker-compose up -d postgres
```
Perform a backup by running the following command:
```shell
docker exec -it <DOCKER_CONTAINER_ID> pg_dump postgres -U postgres > asciinemadump.sql
```
> _**Note**: Your `DOCKER_CONTAINER_ID` information can be obtained from docker `ps command`._
After the database dump process is complete, turn off the PostgreSQL container by running this command:
```shell
docker-compose down
```
delete all volume data used by the **PostgreSQL container** (default is `./volumes/postgres`).
> _**IMPORTANT**: I recommend that you **back up the directory before permanently deleting it**!_
### 2. Run the upstream version of PostgreSQL
After that, **delete the docker volume for PostgreSQL 12** and use the same PostgreSQL version from upstream (`v14`).
Again, edit `docker-compose.yml` and revert the config according to the upstream version:
```yaml
version: '2'
services:
postgres:
image: postgres:14-alpine
container_name: asciinema_postgres
### blah blah blah
```
Turn on PostgreSQL 14, but **leave the other asciinema-server services disabled**.
```shell
docker-compose up -d postgres
```
### 3. Restore PostgreSQL backups
After PostgreSQL that is compatible with the upstream version is running, do the database restore process that we have backed up before.
Copy the `asciinemadump.sql` file to the **Postgres volume** ( default: `./volumes/postgres`) and **change the file permissions** so that the **root user inside the container can read the file**.
Then run the following command to restore the database:
```shell
docker exec -it <DOCKER_CONTAINER_ID> psql -d postgres -U postgres -f /var/lib/postgresql/data/asciinemadump.sql
```
> _**Note**: Your `DOCKER_CONTAINER_ID` will be different from the previous `DOCKER_CONTAINER_ID`. Make sure to use the correct docker container ID._
### 4. Run asciinema-server as usual
After that, run all the `asciinema-server` services as usual (`docker-compose up -d`), and you should be able to **access your self-hosted asciinema-server** again.