⋅ Aucun commentaire

Since openproject doesn't seems to create an admin user, let's do it manually...

  • 1. create your user on the web interface
  • 2. enter the worker container: 
docker ps
docker exec -u root -it <CONTAINER ID> /bin/bash
  • 3. activate your user and make him admin
RAILS_ENV=production bundle exec rails c
u = User.find_by_login "your username"
u.status="active"
u.admin = "true"
u.save
exit
exit
  • 4. ?????
  • 5. PROFIT

⋅ Aucun commentaire

Before upgrade

Backup database! we're going from PostgreSQL 12 direcly to 15:

cd /path/to/misskey
docker-compose stop web # we won't want to get unsaved tooths
docker-compose exec db pg_dumpall -U misskey  > ../mk-dump.sql

Upgrade!

git stash
git checkout master
git pull --no-rebase
git submodule update --init
git stash pop
docker-compose build
docker-compose stop && docker-compose up -d

Post upgrade

Nothing works, you need to reconstruct db from scratch:

docker-compose stop web
docker-compose stop db
sudo rm -rf db
docker-compose start db
mv ../mk-dump.sql db/
docker-compose exec db bash
psql -U misskey -d misskey < /var/lib/postgresql/data/mk-dump.sql
exit

You also need to upgrade to new password encryption:

docker-compose stop db
sudo nano db/postgresql.conf # uncomment password_encryption = scram-sha-256

now you need to upgrade password. get your old password:

cat .config/docker.env
docker-compose start db
docker-compose exec db bash
psql -U misskey -d misskey

you can check before and after if password has been upgraded for new version with this command:

SELECT rolname, rolpassword ~ '^SCRAM-SHA-256\$' AS has_upgraded FROM pg_authid WHERE rolcanlogin;

now upgrade the password (you can reuse old password or change it to a new one)

\password
{enter password}
{enter password again}
quit;
exit

lastly, we start web, and let the upgrade finish itself

docker-compose start web

ET... VOILÀ!

⋅ Aucun commentaire

Si vous avez déjà touché à une distro BSD avant GPT, vous avez déjà du voir à l'installation que vous deviez configurer des "slices" pour y foutre des "partitions" dedans.
Pour faire simple, les slices sont la terminologie BSD pour les partitions étendues, et les partitions BSD sont les partitions logiques.

Pour info, les partitions étendues ont été créées car il ne pouvais y avoir que 4 partitions principales sur un disque dur au format MBR (codée avec 2 bits, donc 00, 01, 10 et 11).
Du coup, la partition étendue était comme un cheat code pour stocker plus de 4 partitions, la partition étendue servant comme un conteneur pour d'autres partitions. C'est aussi pour ça que les partitions contenues dans la partition étendue sous linux commencent par 5 même s'il n'y a pas 4 partitions principales.

⋅ Aucun commentaire

Par exemple, tu as besoin d'un disque de 100Go pour ta vm:

- En Thick lazy zeroed (provisionnement statique, mise à zéro tardive) :
tu bloques les 100Go direct sur ton datastore mais on ne touche pas aux anciennes données présentes sur les secteurs bloqués. En cas d'écriture, le secteur est mis à 0 et ensuite écrit avec la donnée que tu lui envoie. Tu as besoin de plus d'I/O pour écrire ta donnée que juste écrire ce dont tu as besoin.

- En Thick eager zeroed (provisionnement statique, mise à zéro imminente) :
pareil que l'autre mais tes 100Go sont direct mis à 0 sur le disque. C'est long à créer mais niveau perfs à l'usage, c'est le meilleur.

- En Thin (provisionnement dynamique) :
ton disque fait 17Mo sur le datastore et grossi jusqu'à une taille maximum de 100Go. Niveau perfs et fiabilité c'est le moins bon mais le plus rapide à créer et permet de faire l'overprovisionning (allouer plus que ce que ton datastore ne peut contenir). Pareil que pour le lazy zeroed, tu as besoin de pas mal d'I/O (mettre le secteur à 0 et écrire ta donnée) mais en plus la fragmentation est potentiellement plus importante puisque les données de ton disque ne sont pas toutes écrites au même moment (mais c'est pas une généralité).