Projects:Server Migration - Bewerkingsoverzicht

Sjors Gielen op 16 nov 2025 om 13:15

2025-11-16T13:15:40Z

← Oudere versie		Versie van 16 nov 2025 13:15
Regel 43:		Regel 43:

	==== Anti-spam on the mailing list ====		==== Anti-spam on the mailing list ====
	On Altair, e-mail arrives at Postfix which is a component of Mailcow-dockerized. Config is at /etc/mailcow-dockerized. Postfix sends e-mail through Rspamd, which adds headers describing if and why it considers e-mails spam. The most important rule is that if the spam score is higher than 7 (this is configured in <code>/opt/mailcow-dockerized/data/conf/rspamd/local.d/actions.conf</code>), the <code>X~~-Remote~~-Spam-Flag</code> header is added.		On Altair, e-mail arrives at Postfix which is a component of Mailcow-dockerized. Config is at /etc/mailcow-dockerized. Postfix sends e-mail through Rspamd, which adds headers describing if and why it considers e-mails spam. The most important rule is that if the spam score is higher than 7 (this is configured in <code>/opt/mailcow-dockerized/data/conf/rspamd/local.d/actions.conf</code>), the <code>X-Spam-Flag</code> header is added.

	Then, Mailman is configured such that if that header ~~exists~~ in the e-mail, the e-mail is held for moderation instead of forwarded. This way, anyone with a broken e-mail configuration can still send to the mailinglist and we can choose to accept the e-mail. But, spam is likely not forwarded directly to the list. This configuration is at <code>/opt/mailman/core/mailman-extra.cfg</code>.		Then, Mailman is configured such that if that header (or several others) exist in the e-mail, the e-mail is held for moderation instead of forwarded. This way, anyone with a broken e-mail configuration can still send to the mailinglist and we can choose to accept the e-mail. But, spam is likely not forwarded directly to the list. This configuration is at <code>/opt/mailman/core/mailman-extra.cfg</code>.

	You can test whether such e-mails are held by sending an e-mail to the list with the following header in it: <code>X~~-Remote~~-Spam-Flag: YES</code>. Alternatively, put the ~~following text in the body~~ to ~~give it~~ a ~~very high~~ spam score~~: <code>GTUBE1~~.~~01A2.1234567890123456789012345678901234567890123456789012345678901234567890</code>~~<br />		You can test whether such e-mails are held by sending an e-mail to the list with the following header in it: <code>X-Spam-Flag: YES</code>. Alternatively, if you put a subject that's over 200 characters and allcaps, this adds a +6 to the spam score, so if you're also missing Message-Id, Date and various other relevant headers then it's easy to get a spam score above 7 and the mail will be rejected as spam.<br />

Sjors Gielen op 16 nov 2025 om 12:36

2025-11-16T12:36:58Z

← Oudere versie		Versie van 16 nov 2025 12:36
Regel 41:		Regel 41:

	If everything goes to plan, we can cancel the old server contract within 14 days.		If everything goes to plan, we can cancel the old server contract within 14 days.
	<br />
			==== Anti-spam on the mailing list ====
			On Altair, e-mail arrives at Postfix which is a component of Mailcow-dockerized. Config is at /etc/mailcow-dockerized. Postfix sends e-mail through Rspamd, which adds headers describing if and why it considers e-mails spam. The most important rule is that if the spam score is higher than 7 (this is configured in <code>/opt/mailcow-dockerized/data/conf/rspamd/local.d/actions.conf</code>), the <code>X-Remote-Spam-Flag</code> header is added.

			Then, Mailman is configured such that if that header exists in the e-mail, the e-mail is held for moderation instead of forwarded. This way, anyone with a broken e-mail configuration can still send to the mailinglist and we can choose to accept the e-mail. But, spam is likely not forwarded directly to the list. This configuration is at <code>/opt/mailman/core/mailman-extra.cfg</code>.

			You can test whether such e-mails are held by sending an e-mail to the list with the following header in it: <code>X-Remote-Spam-Flag: YES</code>. Alternatively, put the following text in the body to give it a very high spam score: <code>GTUBE1.01A2.1234567890123456789012345678901234567890123456789012345678901234567890</code><br />

Uartist op 28 feb 2023 om 14:44

2023-02-28T14:44:00Z

← Oudere versie		Versie van 28 feb 2023 14:44
Regel 33:		Regel 33:
	Update: the migration is complete, but there are some quirks:		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.		* <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 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.		* The mailing list should work, but needs to be tested thoroughly.

Uartist op 27 feb 2023 om 22:37

2023-02-27T22:37:38Z

← Oudere versie		Versie van 27 feb 2023 22:37
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.

	~~'''<big>Please, do not use the mailinglist or update the wiki until the migration is completed. I will do my best to have it ready tomorrow or early tuesday.</big>'''~~

	A quick summary:		A quick summary:
Regel 32:		Regel 30:
	*hsnmgn.nl is also not (widely) known, meaning that we also might consider to ditch that one as well		*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'''.		*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.
			* 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.


	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~~.		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.		If everything goes to plan, we can cancel the old server contract within 14 days.
	<br />		<br />

Uartist op 27 feb 2023 om 01:45

2023-02-27T01:45:38Z

← Oudere versie		Versie van 27 feb 2023 01:45
Regel 31:		Regel 31:
	*stichtinghackerspacenijmegen.nl was only used in the previous setup, meaning this domain could potentially be ditched		*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		*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'''.

Uartist op 27 feb 2023 om 01:41

2023-02-27T01:41:59Z

← Oudere versie		Versie van 27 feb 2023 01:41
Regel 8:		Regel 8:

	*40GB HDD (yes, not SSD) and 2GB RAM		*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		*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).		*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		*Docker, minus iptables

Uartist op 27 feb 2023 om 01:41

2023-02-27T01:41:05Z

← Oudere versie		Versie van 27 feb 2023 01:41
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.

			'''<big>Please, do not use the mailinglist or update the wiki until the migration is completed. I will do my best to have it ready tomorrow or early tuesday.</big>'''

	A quick summary:		A quick summary:

	== The old server (corvus) ==		==The old server (corvus)==

	*40GB HDD (yes, not SSD) and 2GB RAM		*40GB HDD (yes, not SSD) and 2GB RAM
Regel 13:		Regel 15:
	*Webhosting using php-fpm (7.3) and nginx		*Webhosting using php-fpm (7.3) and nginx

	== The new server (altair) ==		==The new server (altair)==

	*80GB SSD, 8GB RAM		*80GB SSD, 8GB RAM
Regel 22:		Regel 24:
	*BIND for dynamic updates of the space connection		*BIND for dynamic updates of the space connection
	*A proxy method delivering the DNS-traffic for the respective zones to the right server		*A proxy method delivering the DNS-traffic for the respective zones to the right server
	*Webhosting using php-fpm (8.2) and nginx		*Webhosting using php-fpm (8.2) and nginx

	== Trivia ==		==Trivia==

	* The new server hostname's FQDN is altair.hackerspacenijmegen.nl		*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		*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		*hsnmgn.nl is also not (widely) known, meaning that we also might consider to ditch that one as well

Uartist op 27 feb 2023 om 01:39

2023-02-27T01:39:45Z

← Oudere versie		Versie van 27 feb 2023 01:39
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 />

Uartist op 27 feb 2023 om 01:34

2023-02-27T01:34:07Z

← Oudere versie	Versie van 27 feb 2023 01:34
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
		*

Uartist: Lege pagina aangemaakt

2023-02-27T01:15:47Z

Lege pagina aangemaakt

Nieuwe pagina