# NetSurf migration to Infrafish (DNS/Mail), Freelists (MLs), and NS infra (git/www)

Things to migrate include:

* DNS hosting
* MX fronting
* Mailing lists
* Git server
* Web hosting (www. as well as git.)
* Wiki hosting
* SSL certificate generation

## Infrafish approach

Infrafish is limited to: DNS hosting, MX fronting, and static website serving

As such, Daniel suggests that we move all websites to NS infra, along with the git server, as that gives the greatest chance that ikiwiki et al. can be made to "just work".

Possible transition plan is:

1. Set up DNS and MX on infrafish with:
- DNS set up so web etc. still points at pepperfish
- Done
- all main aliases in place
- Done
- mxc.pepperfish.net as remote-mx so that mailman lists continue to function to some extent
- Done
- no SPF record for now
- Done/Removed
- Worth noting we had a DMARC record of: `v=DMARC1; p=none; sp=none; fo=1; ri=3600`
2. Update whois records to push DNS and main MX over to infrafish
- Done
3. Send an email to a mailing list, from outside of infrafish, to ensure that the lists continue to work.
- Done(ish) I sent from infrafish, but all looks OK for now.

## Mailing lists

Daniel has emailed Freelists staff to confirm that they think it'll be
acceptable for NS mailing lists to be hosted there. Once they reply we'll look
at moving there. If they say that it's not acceptable then there're other
options though they cost money. Based on our subscriber numbers it'd be over 100
per year for mailmanlists.org for example. (they go on subscriber count, not
throughput) All other options Daniel has explored are VPS/hosts which offer
integrated mailman support, but the goal is to not have to run our own ML
server.

### Freelists

Freelists turns out to be perfect.

Daniel has experimented with a list and the following is what we need in order
to complete the process

1. Create each of the lists we need on freelists
- Proposal: Daniel to create them since he's subscribed to them all
- Recommendation: Once the membership is imported, jmb, tlsa, kyllikki
all become marked as admins of the list
2. Daniel to supply to freelists staff the subscriber CSVs and links to
where mbox files for the list archives will be placed
3. Once CSVs imported, admin settings are done
- Someone needs to take ownership of setting up things like the welcome
messages etc. But this doesn't have to happen immediately
- For the commits list, we need to ensure that the commit mailer has
the ability to post and nobody else does.
4. Daniel resets mail configs to point at freelists
- From this point on, freelists is actually running the mailing lists
5. Daniel then creates the mboxes and signals freelists staff to begin
archive importing.
6. Someone posts to the lists to let everyone know, to thank Freelists for
hosting the lists, and to indicate how to unsubscribe if anyone is unhappy
with the move.

* [e-mail]
* [e-mail]
* [e-mail] and [e-mail]

## Moving git et al.

The git server, website, and wiki, are somewhat inextricably linked. And the
git server expects to be able to ping CI as well.

In order to process things cleanly, we should stop the access to the git server
for writes on pepperfish *before* we proceed.

A wholesale copy of the netsurf home directory from Pepperfish to a user on the
relevant NS host seems the most sensible. If at all possible as the user `netsurf`
though we can probably cope if the homedir paths change. (it is 3.3G currently,
and does contain setuid-netsurf binaries, so rsync perhaps?)

To make git work we will need:

1. Gitano et al. working - so long as the new host is sufficiently compatible this
should be a no-brainer as it's entirely self-contained Daniel thinks
2. An `nsgit` user set up appropriately:
`nsgit:x:1015:1015:NetSurf Git:/home/netsurf/gitano-root/:/bin/sh`
is how it's done on Pepperfish
3. If we can confirm that gitano is then working; we can move on to ensuring that it
can ping CI by pushing some null-ish commit
4. Once satisfied, we need to set up a cgit server or similar, before redirecting the
DNS to the new host. The cgit site in the homedir has a cgit binary which might
be the easiest thing for that.

Next sort the rest of the static websites from ~/websites. For now Daniel suggests
that we only actually implement: download, git, test, wiki, and www; and that we
ignore www2, ipv6, staging-area, planet, download2. We can add those in later if
they prove necessary.

To make the wiki able to respond to pushes, we will need:

1. Ikiwiki installed. Platypus had 3.20150107 - no idea what is current or how that
might affect things
2. Once installed, send some null commit to the wiki and see what happens