Après plus de 24h de coupure, on décide de migrer les services email vers un autre site pour éviter de perdre des emails qui seraient dans la file de serveurs emails à destination de deuxfleurs.
- ✅ vérifier que les autres entrées DNS (A,AAAA, MX) sont comme il faut :
+ ✅ MX deuxfleurs.fr (pas besoin de modifier, il pointe bien vers smtp.deuxfleurs.fr)
+ ✅ A smtp.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+ ✅ AAAA smtp.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+ ✅ A imap.deuxfleurs.fr (pas besoin de modifier à la main en fait, d53 s'en charge en fait !)
+ ✅ AAAA imap.deuxfleurs.fr (pas besoin de modifier à la main, d53 s'en charge !)
- ✅ comprendre où étaient stockés les données des emails sur ananas (chemin sur le FS)
+ a priori /mnt/ssd/mail d'après la feuille de route précédente
+ retrouvable dans le fichier hcl du service email -> /mnt/ssd/mail en effet
- ✅ stopper le service nomad email (FAIT)
+ ça devrait être OK vis à vis des enregistrement DNS et D53, car D53 ne gère pas le MX (si on retire un enregistrement DNS et quelqu'un fait une requête il va recevoir un NXDOMAIN qui sera peut être mis en cache pendant plus longtemps que l'on voudrait)
- ✅ pause pendant le transfert des données !
- ✅ faire des tests sur les données ?
+ ✅ verifier que le chemin est ok (/var/ssd/mail et pas /var/ssd/mail/mail/ - restic est piegeur)
+ ✅ il y a bien les users
+ que peut-on faire de plus que faire confiance à restic ?
- ✅ vérifier que les permissions (owner/group/etc) des fichiers sont ce qu'on veut
- ⌛ renommer le dossier contenant les données mail en mail_deprecated
- ⌛ faire un diff entre les données sur ananas et les données du backup que l'on a restore
- ⌛ migrer les données du diff si on peut ?
+ On peut probablement se baser sur les dates de création des fichiers sur ananas
## Exemple de message à envoyer aux blocklists
### Reason for removal request
> [EN] Deuxfleurs (deuxfleurs.fr) is an experimental & alternative non-profit email provider. This is why we are sending (legitimate!) emails from a residential IP address. We are sending mainly organic emails and few transactional emails (we don't do marketing or newsletter emails). We have strict policies to ensure that emails sent from our servers are legitimate, here is a non-exhaustive list of our trust policy: account creation is manually validated, our SMTP server is authenticated (no SMTP open relay), SPF, DKIM & DMARC are configured, our servers are closely monitored. We operate from a static IPv4 and IPv6 block bound to the fiber line allocated by the ISP, hence the dial-up classification. Thanks in advance for keeping the Internet an open place!
> [FR] Deuxfleurs (deuxfleurs.fr) est une association fournissant des services d'hébergement email, et nous hébergeons nos services derrière des adresses IP résidentielles.
> Nous envoyons principalement des emails non-automatisés (ni emails marketing ou démarchage). Nous implémentons des politiques strictes pour garantir que les emails envoyés depuis nos serveurs sont légitimes : les comptes sont validés manuellement par les administrateurs, notre serveur SMTP est authentifié (pas de relai SMTP ouvert), nous avons configuré SPF, DKIM et DMARC, et nos serveurs sont monitorés.
> Nos serveurs opèrent derrière des IPv4 et IPv6 statiques liés à une ligne fibre FTTH (IPs probablement allouées précédemment par le FAI à des lignes DSL).
> Merci d'avance !
### Reason why the IP address is not in static allocation
> This is a static allocation from the ISP. This used to be an IP address associated with DSL lines from our ISP, now recycled for FTTH lines.
# Feuille de route cryptpad
- problème : les backups sont probablement toujours faits depuis un ancien déploiement cryptpad
+ confirmer ça -> oui en effet
- si c'est bien ça, quelle taille font les données cryptpad ? Adrien peut-il les uploader en 4g en se connectant en local à ananas ?
+ Probablement autours de 1.5/2Gio, vu que c'est ce que Quentin a récupéré du backup qui n'est pas si vieux que ça
+ c'est l'ordre de grandeur de quand on a fait la snapshot de migration aussi
...
- ✅ changer la source des backups cryptpad vers le nouveau déploiement
# Cheatsheet
## Backups
Pour lister et récupérer un backup, depuis le dépot nixcfg:
- les backups de cryptpads qui sont cassés => réfléchire a une stratégie de *tests* de backups
- on pourrait setup un MX secondaire qui queue indéfinimenet et essaie de push sur le primaire, pour pas perdre d'emails entrants en cas de down de la zone principale. /!\ a bien backup aussi cette queue
+ MX secondaire
+ sur le primaire, penser a bind la queue postfix aussi (ajd on pourrait perdre des emails récement reçu, mais pas encore délivré)
- on a encore des backups de plume, mais ils sont vieux. p-e plus besoin maintenant que les médias sont sur s3?
- hcl de backups => cron deprecated, use crons instead (ça accept les listes de cron maintenant)
