Projects:Server Migration: verschil tussen versies

Uit Hackerspace Nijmegen Wiki
Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
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.
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)
A quick summary:


* 40GB HDD (yes, not SSD) and 2GB RAM
== The old server (corvus) ==
* 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)
*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 (7.3) and nginx


* 80GB SSD, 8GB RAM
== The new server (altair) ==
* 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.
*80GB SSD, 8GB RAM
* Bog-standard Docker and iptables setup, nothing special.
*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.
* acme-dns to replace the custom authentication hook script for certbot. It is well thought-out and widely used, written in Go.
*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.
* BIND for dynamic updates of the space connection
*Bog-standard Docker and iptables setup, nothing special.
* A proxy method delivering the DNS-traffic for the respective zones to the right server
*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
*Webhosting using php-fpm (8.2) and nginx
 
== Trivia ==
 
* The new server hostname's FQDN is altair.hackerspacenijmegen.nl
* stichtinghackerspacenijmegen.nl was only used in the previous setup, meaning this domain could potentially be ditched
* hsnmgn.nl is also not (widely) known, meaning that we also might consider to ditch that one as well
 
 
At the time of writing, only the website part needs to be moved. The mail setup has already been synchronized; when the reverse DNS has been updated I will pull the plug.
 
If everything goes to plan, we can cancel the old server contract within 14 days.
<br />

Versie van 27 feb 2023 01:39

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.

A quick summary:

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 (7.3) 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
  • Webhosting using php-fpm (8.2) and nginx

Trivia

  • The new server hostname's FQDN is altair.hackerspacenijmegen.nl
  • stichtinghackerspacenijmegen.nl was only used in the previous setup, meaning this domain could potentially be ditched
  • hsnmgn.nl is also not (widely) known, meaning that we also might consider to ditch that one as well


At the time of writing, only the website part needs to be moved. The mail setup has already been synchronized; when the reverse DNS has been updated I will pull the plug.

If everything goes to plan, we can cancel the old server contract within 14 days.