Projects:Server Migration: verschil tussen versies

Uit Hackerspace Nijmegen Wiki
Naar navigatie springen Naar zoeken springen
(Lege pagina aangemaakt)
 
Geen bewerkingssamenvatting
Regel 1: Regel 1:
Problem summary: We have a hosting node at Tilaa, being very underpowered and causing problems due to resource constraints. Back in 2022, we agreed on moving our digital assets to a new provider. However, due to several reasons, this project has been postponed. Recently we picked op the pace again, as we are currently paying twice for our hosting. This opportunity is also a great moment to simplify our setup and say goodbye to custom solutions requiring a lot of time to manage, troubleshoot and maintain.


The old server (corvus)
* 40GB HDD (yes, not SSD) and 2GB RAM
* Runs mailu as the mailserver (basically a flask webapp managing postfix and dovecot), picked at the time because it was light on resources
* Mailman3, running the mailing list. There are problems as sqlite has been chosen, again, due to resouce constraints. Migrating this to mysql or postgres will be either a headache or next to impossible (within a reasonable timeframe).
* Docker, minus iptables
* A custom, completely manual firewall setup in nftables. At the time, docker's support for IPv6 was lackluster at best, which needed this solution. However, things have improved recently on that front.
* A BIND webserver handling LetsEncrypt wildcard challenges using a custom script and providing dynamic DNS updates for the space connection.
* Webhosting using php-fpm and nginx
The new server (altair)
* 80GB SSD, 8GB RAM
* Uses Mailcow as it's email server, a well-maintained and widely used open source project backed by a German company. The support is excellent and updates very frequent.
* Mailman3 as the mailinglist. For the time being, the choice has been made to move the SQLite database to the new server and just move on. It works: if and how we migrate the contents to a new database system or simply start clean can be decided on later.
* Bog-standard Docker and iptables setup, nothing special.
* acme-dns to replace the custom authentication hook script for certbot. It is well thought-out and widely used, written in Go.
* BIND for dynamic updates of the space connection
* A proxy method delivering the DNS-traffic for the respective zones to the right server
*

Versie van 27 feb 2023 01:34

Problem summary: We have a hosting node at Tilaa, being very underpowered and causing problems due to resource constraints. Back in 2022, we agreed on moving our digital assets to a new provider. However, due to several reasons, this project has been postponed. Recently we picked op the pace again, as we are currently paying twice for our hosting. This opportunity is also a great moment to simplify our setup and say goodbye to custom solutions requiring a lot of time to manage, troubleshoot and maintain.

The old server (corvus)

  • 40GB HDD (yes, not SSD) and 2GB RAM
  • Runs mailu as the mailserver (basically a flask webapp managing postfix and dovecot), picked at the time because it was light on resources
  • Mailman3, running the mailing list. There are problems as sqlite has been chosen, again, due to resouce constraints. Migrating this to mysql or postgres will be either a headache or next to impossible (within a reasonable timeframe).
  • Docker, minus iptables
  • A custom, completely manual firewall setup in nftables. At the time, docker's support for IPv6 was lackluster at best, which needed this solution. However, things have improved recently on that front.
  • A BIND webserver handling LetsEncrypt wildcard challenges using a custom script and providing dynamic DNS updates for the space connection.
  • Webhosting using php-fpm and nginx

The new server (altair)

  • 80GB SSD, 8GB RAM
  • Uses Mailcow as it's email server, a well-maintained and widely used open source project backed by a German company. The support is excellent and updates very frequent.
  • Mailman3 as the mailinglist. For the time being, the choice has been made to move the SQLite database to the new server and just move on. It works: if and how we migrate the contents to a new database system or simply start clean can be decided on later.
  • Bog-standard Docker and iptables setup, nothing special.
  • acme-dns to replace the custom authentication hook script for certbot. It is well thought-out and widely used, written in Go.
  • BIND for dynamic updates of the space connection
  • A proxy method delivering the DNS-traffic for the respective zones to the right server