Categorie: migratie

Geplaatst op

Yunohostmigratie

Migratie van opensoos.nl naar een krachtigere server.

Op zich werkte alles wel, maar… vaak na wachten, en meestal niet tegelijkertijd. De server was destijds over, zat ruim genoeg in z’n jasje om er meerdere diensten tegelijk op te draaien, en had voldoende opslagruimte om beeldmateriaal weg te schrijven.

De specificaties, beknopt uit de YABS-header:

  • Processor  : Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHz
  • CPU cores  : 1 @ 2593.906 MHz
  • RAM        : 1.9 GiB
  • Swap       : 1.0 GiB
  • Disk       : 98.4 GiB
  • Distro     : Debian GNU/Linux 12 (bookworm)
  • Kernel     : 6.1.0-43-cloud-amd64
  • VM Type    : KVM
  • IPv4/IPv6  : ✔ Online / ✔ Online

Zoals gezegd, de server verslikte zich in de workload, terwijl ik nog niet klaar was. Er draaide nu:

  • BookWyrm voor boekbesprekingen
  • flohmarkt voor advertenties
  • Mastodon voor korte berichtjes
  • PeerTube voor videomateriaal
  • Pixelfed voor fotomateriaal
  • SnappyMail om mail te lezen

SnappyMail zal ‘m de das niet omgedaan hebben, maar sommige van de Fediverse-apps zijn vrij zwaar. Daaroverheen wilde ik in ieder geval een ‘verzamel alles’-dienst draaien (*key of *fish variant), eventueel een link-aggregator zoals Lemmy, en misschien, als dat bestaat, een muziek/geluidsfragmentendienst. Om de zaak te beschrijven zou er een ‘social-enabled’ WordPress bij mogen.

Dat zou deze server zeker niet trekken. Het zijn federated diensten, dus ik zou het geheel … federated op kunnen zetten, maar ik wil dit hele zwikje enigszins overzichtelijk houden en op een machine laten draaien.

Zodoende, migreren naar een zwaardere machine. Beschikbaar:

  • Processor  : AMD EPYC 7313 16-Core Processor
  • CPU cores  : 2 @ 3000.000 MHz
  • AES-NI     : ✔ Enabled
  • VM-x/AMD-V : ✔ Enabled
  • RAM        : 3.8 GiB
  • Swap       : 1.5 GiB
  • Disk       : 79.9 GiB
  • Distro     : Debian GNU/Linux 12 (bookworm)
  • Kernel     : 6.1.0-9-amd64
  • VM Type    : KVM
  • IPv4/IPv6  : ✔ Online / ✔ Online

Weliswaar met minder opslagruimte, maar alles minstens dubbel zo snel. Meer opslagruimte kan vast via een S3-provider aangevuld worden, eventueel van de oude server.

Stappenplan

Oude server : A
Nieuwe server: B

  • Op B
    • Schone installatie van Debian 12 (momenteel, Yunohost 12) via de managementsinterface van de hoster
    • Installeer Yunohost: curl https://install.yunohost.org | bash
    • Creeer zonodig SSH ids, voeg ‘t public ID van root@A toe aan .ssh/authorized_keys
    • Ontvang de backup van A
    • Restore de zojuist ontvangen backup, in plaats van de reguliere postinstall : yunohost backup restore 20260212
    • Push vanuit Yunohost de gewijzigde IP’s naar DNS, of doe het met de hand
  • Op A
    • Vergroot, wegens performance, swap: fallocate -l 1G /swap2 && chmod 600 /swap2 && mkswap /swap2 && swapon /swap2
    • Backup: yunohost backup create
    • Hernoem de server : hostname -b old.opensoos.nl && echo 'old.opensoos.nl > /etc/hostname
    • Creeer zonodig SSH ids: ssh-keygen -t ed25519
    • Test SSH: ssh root@opensoos.nl (zonder reboot van A wijst dit nog naar localhost, gebruik evt ‘t IP van B)
    • Kopieer de backup van A naar B: scp 20260212-223700.*  root@opensoos.nl:/home/yunohost.backup/archives

In grote lijnen verliep de boel volgens plan, maar na afloop:

  • Mastodon was niet geinstalleerd
    • Verkeerde bundler-versie ; handmatig geinstalleerd
      • apt install gem
      • gem install bundler -v ‘~> 2.6’
      • Ook na die handmatige ingreep liep restore op hetzelfde punt stuk
    • Backup-tar uitpakken, en controleren of er ergens een bundler-installatie plaatsvindt
      • ja, inderdaad: ynh_gem install bundler --no-document; aangepast naar ynh_gem install bundler -v '~> 2.6' --no-document en de tar bundel weer geupload voor een nieuwe poging
      • Daarmee slaagt restore van Mastodon
  • Peertube was niet geinstalleerd :
    • 2026-02-12 20:59:42,714: WARNING - Feb 12 20:54:42 (node)[33774]: peertube.service: Failed to locate executable /opt/node_n/n/versions/node/22.21.1/bin/node: No such file or directory
      2026-02-12 20:59:42,715: WARNING - Feb 12 20:54:42 (node)[33774]: peertube.service: Failed at step EXEC spawning /opt/node_n/n/versions/node/22.21.1/bin/node: No such file or directory
      2026-02-12 20:59:42,716: WARNING - Feb 12 20:54:42 systemd[1]: peertube.service: Main process exited, code=exited, status=203/EXEC 2026-02-12 20:59:42,716: WARNING - Feb 12 20:54:42 systemd[1]: peertube.service: Failed with result 'exit-code'.
    • Peertube op de oude server had nog geen federatie of interactie met de buitenwereld –> herinstallatie
    • Herinstallatie ging zonder problemen, maar na afloop kon ik mijn Yunohost-gebruikers niet vinden; de LDAP-plugin had geen configuratieparameters (“This plugin does not have any configuration”).
    • LDAP-plugin verwijderd, opnieuw geinstalleerd; kon nu wel geconfigureerd worden volgens de Yunohost-instructies
      • Login voor de eerste de beste Yunohost gebruiker werkte niet
      • oorzaak blijkt: die gebruiker was al als root/admin aangemaakt in Peertube
        • andere gebruikers konden wel via LDAP inloggen
        • na aanpassen van het emailadres van root/admin in Peertube, kon ook die YNH-gebruiker als reguliere Peertube-user inloggen via LDAP
  • Flohmarkt wilde niet starten
    • De oorspronkelijke oorzaak heb ik niet achterhaald, ik kwam er pas achter nadat ik een upgrade deed
    • Nieuwe installatie gaf ook een probleem
    • Zodoende opnieuw de backup teruggezet, die bleek meteen niet te functioneren:
      • Het numerieke ID van systeemgebruiker ‘flohmarkt’ kwam niet overeen met het numerieke ID van ‘flohmarkt’ in de backup. Rechtzetten door:
      • root@opensoos:/var/www# find . -uid 987 -exec chown flohmarkt {} +
      • root@opensoos:/var/www# find . -gid 987 -exec chgrp flohmarkt {} +

In grote lijnen was de migratie geslaagd, maar een paar dingen liepen niet helemaal lekker. Een log van m’n werkzaamheden is verloren gegaan, de details ontbreken zodoende:

  • flohmarkt start niet:
    • de flohmarkt-gebruiker was met een ander numeriek ID aangemaakt op de nieuwe server, waardoor de systeemgebruiker geen toegang kreeg tot z’n ‘eigen’ bestanden
    • hersteld door de bestanden en directories op basis van de numerieke ID’s aan de correcte gebruiker toe te wijzen:
      • /var/www# find . -uid 987 -exec chown flohmarkt {} +
      • /var/www# find . -gid 987 -exec chgrp flohmarkt {} +
  • Peertube plugins plugden niet in :
    • Het leek of de plugins wel geinstalleerd waren, maar niet bruikbaar waren. Geen van de benodigde configuratieopties was beschikbaar.
    • Een van de plugins verzorgt de koppeling met Yunohost SSO ; zodoende kon er niet ingelogd worden
    • Verwijderen en opnieuw installeren/configurerern van de plugins heeft dat verholpen
    • Vervolgprobleem :
      • een van de gebruikers kon alsnog niet inloggen. Het bleek dat ik in tegenstelling tot hoe het op de oorspronkelijke server ingericht was, voor de peertube-root-user een emailadres van een van de Yunohost-users had gebruikt.
      • LDAP matcht gebruikers in dit geval op emailadres. Omdat het emailadres van die Yunohost-user reeds aan de Peertube-root-user gekoppeld was, kon die betreffende gebruiker niet inloggen.
      • Hersteld door het emailadres van de Peertube-root-user aan te passen naar een ander emailadres
  • BookWyrm:
    • Ik meen me te herinneren dat herstel van de backup van BookWyrm niet slaagde
    • BookWyrm was nog een lege installatie, ik heb ervoor gekozen dat opnieuw te installeren.

Vervolg

De migratie speelde een week of twee terug. Openstaande punt was toen nog om een ‘centrale’ sociale plaats te definieren, waar de verschillende mediaspecifieke sociale identiteiten in uitmonden.

Kandidaatnetwerken voor de centrale identiteit waren na een eerste schifting op basis van beschikbaarheid in de Yunohost catalogus, features, aantal gebruikers en aantal ontwikkelaars:

  • Friendica
  • *key
    • Misskey
    • Sharkey
    • Iceshrimp

Sharkey is als winnaar uit de bus gekomen. Installatie slaagde na toevoegen van wat extra swap-ruimte.

Print this entry

Geplaatst op

VPS-migratie

Een van de VPS’en zit vol. Uitbreiden van de opslagruimte is niet (goedkoop) mogelijk, maar omdat het er al een tijdje aan zat te komen, heb ik een ruimere VPS beschikbaar.

Bij een eerdere migratie, van thuis naar VPS, heb ik een howto op lowendspirit gevolgd waarmee het disk-image goed te versturen was. Ik had nu moeite hem weer terug te vinden, dus voor de volgende keer leg ik het hier ook vast.

Het idee is in grote lijnen:

  • Sluit de draaiende server af, om een statische situatie te hebben zodat het bestandssysteem consistent blijft.
  • Start een rescue-mode op de VPS-omgeving. In de rescue-mode zijn de diskpartities van de VPS beschikbaar.
  • Kopieer de partitie van de ene machine naar de andere machine met dd over SSH

In dit geval is het resultaat: 

rescue # dd if=/dev/vda bs=32M status=progress | ssh -C root@185.193.158.65 "dd of=/dev/vda"
The authenticity of host '185.193.158.65 (185.193.158.65)' can't be established.
RSA key fingerprint is SHA256:+EhOiwW9GjD4wv2S/0eRveRdoxV8Mlf1x8sICc9JxUY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '185.193.158.65' (RSA) to the list of known hosts.
root@185.193.158.65's password: 
973078528 bytes (973 MB, 928 MiB) copied, 35.8094 s, 27.2 MB/s

De partitie gaat van een datacenter in Frankfurt naar eentje in Amsterdam. De doorvoersnelheid stabiliseert zich op iets boven 33 MB/s, waarmee de partitie van 20 GB in ongeveer 10 minuten gekopieerd is.

De partitie is meteen al 40 GB, maar het bestandssysteem is nog 20 GB. Met resize2fs kan de grootte van het ext4-bestandssysteem aangepast worden: 

# e2fsck -f /dev/vda
e2fsck 1.46.2 (28-Feb-2021)
Pass 1: Checking inodes, blocks, and sizes
....
# resize@fs /dev/vda
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/vda to 10485760 (4k) blocks.
The filesystem on /dev/vda is now 10485760 (4k) blocks long. 
#

Het enige probleem is dat het doelsysteem niet boot. Als ik de schijf boot in rescue-modus, staat alle data er op, inclusief de bootdirectory.

Wat blijkt? Bij het kopieren heb ik uit gewoonte de eerste partitie van de schijf (/dev/vda1) gepakt, terwijl er op de doelserver geen partitie is de schijf zit: het had /dev/vda1 ipv /dev/vda moeten zijn, of allebei /dev/vda.

Opgelost vanuit een system-rescue door:

  • Bestandssysteem krimpen tot minimum, de grootte van de bezette ruimte (resize2fs -M)
  • Nogmaals kopieren, nu van /dev/vda1 naar /dev/vda
  • Bestandssysteem laten groeien tot partitiegrootte

Het systeem bootte toen wel, maar de netwerkconfiguratie was nog die van de oude server. Toen het eenmaal half-en-half werkte, vond ik de ‘reconfigure networking’ knop in de Solus-management-omgeving.

Daarmee werkte routing voor IPv6 weer; DNS was al gecorrigeerd.

Nu lijkt alles weer naar behoren te werken, met ruim het dubbele aan beschikbare ruimte.

Print this entry