Projects:Server Migration: verschil tussen versies

Uit Hackerspace Nijmegen Wiki
Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
Geen bewerkingssamenvatting
 
(5 tussenliggende versies door dezelfde gebruiker niet weergegeven)
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. Slightly modified to play ball with the mailinglist, making upgrades painful.
*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
*This combined will save us '''€254 a year'''.
 
Update: the migration is complete, but there are some quirks:
 
* <s>For some reason, MediaWiki doesn't send emails anymore. There are no logs, there are no delivery attempts at the mailserver and the debug log doesn't even mention the email module being invoked. I triple checked the configuration, but it's seems okay. I am clueless at this point.</s>  28-02-2023: mrngm and I looked into this issue again and it has now been solved.
* The spacestate still uploads the json file to the old server. We need to migrate that ASAP, I proposed a new solution to Sjors.
* The mailing list should work, but needs to be tested thoroughly.
 
 
docs.hackerspacenijmegen.nl, the old WordPress homepage and the unused WordPress at stichtinghackerspacenijmegen.nl have been retired. A copy of the webroot and database of the respective websites can be found on the new server.☃☃
 
If everything goes to plan, we can cancel the old server contract within 14 days.
<br />

Huidige versie van 28 feb 2023 om 14:44

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. Slightly modified to play ball with the mailinglist, making upgrades painful.
  • 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
  • This combined will save us €254 a year.

Update: the migration is complete, but there are some quirks:

  • For some reason, MediaWiki doesn't send emails anymore. There are no logs, there are no delivery attempts at the mailserver and the debug log doesn't even mention the email module being invoked. I triple checked the configuration, but it's seems okay. I am clueless at this point. 28-02-2023: mrngm and I looked into this issue again and it has now been solved.
  • The spacestate still uploads the json file to the old server. We need to migrate that ASAP, I proposed a new solution to Sjors.
  • The mailing list should work, but needs to be tested thoroughly.


docs.hackerspacenijmegen.nl, the old WordPress homepage and the unused WordPress at stichtinghackerspacenijmegen.nl have been retired. A copy of the webroot and database of the respective websites can be found on the new server.☃☃

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