Goodbye NethServer, Hello Cloudron

If you've read my previous posts you've seen that I'm a big fan of self-hosting. I've been using NethServer for at least 5 years, but it seems our time is up. NethServer decided that while doing the necessary move away from CentOS they would also redesign their server to be containerized -- Awesome!

Except, they also decided that having security baked in to your server isn't necessary. They split firewall and other security measures into a different offering, and expect everyone running NethServer to run TWO servers when one worked just fine before.

Unfortunately, I just can't agree with this. Whether they realize it or not, this is a significant shift towards small businesses and away from individuals.

The more I look back at NethServer, the more it's clear there's a core group of IT professionals who use it heavily for the server basics: user directory, e-mail, and even VOIP. Anything outside of that doesn't get much attention.

I kept researching what to move to, and then procrastinating on my move. As much as I believe in self-hosting, moving servers is a pain and I really wish I didn't need to. WHY did NethServer make this change? Oh well. After 3 iterations of researching and reviewing, the time came that I really needed to make a move because the base OS no longer had security updates available. I checked CasaOS, I checked Umbrel, I even went and checked YunoHost again.

Overall, there were two key features that knocked most options out of the running:

1 - No Self-hosted E-mail

Some of the really pretty options, like CasaOS or Umbrel, fall on their face because they only have a webmail app, and can't actually host an e-mail server.

It's pretty easy to find posts saying "Don't host e-mail, it's too hard, it's a losing battle", and so on. But in my opinion, it doesn't matter how many apps you self-host if all your sensitive e-mails go through a third party. It most certainly is not easy to run your own e-mail server, but that's exactly why we must. Otherwise, Google and Microsoft will basically run all e-mail in a matter of years.

2 - Bad App Selection

Unfortunately some of the offerings with really good app selection didn't offer self-hosted e-mail, so they're out. I have even less time than before to deal with hosting my own apps in Docker containers or writing those compose files myself, so I really need something with a good selection of supported apps. I'm even willing to pay for that!

At the time of writing, NethServer 8 has 17 official apps and 6 unofficial apps. 4 of these apps are basic things that shouldn't really be counted, like web server, web mail, file server, and mail server. I had two subscriptions to NethServer and went through a lot of pain to host apps myself, but their decision to force separating security and hosting into two servers I simply could not abide.

Enter Cloudron

Cloudron seems to have the perfect mix: self hosted e-mail, single server, and an impressive app selection (167 apps right now). At first I was a bit hesitant to go with them because I saw some apps that were previously supported get de-listed. It turns out they often de-list apps because upstream has become stagnant and is not maintaining security. Not a bad reason to stop supporting an app.

I've now finished the migration of one server and have some notes to share below about the process. I'm waiting for Cloudron to support XMPP so I can move my other server. I've been very happy with Cloudron so far!

My Migration Path

Unfortunately there's no easy way to move between these two options, so I had to go one app at a time.

E-Mail

Before: Built-in NethServer option
After: Built-in Cloudron option
Steps Needed:
- Update DNS records
- Copy mailboxes using imapsync

The only "gotcha" here is even though imapsync and most mail servers support allowing an admin to sign in as other users and copy the data for them, Cloudron does not. So instead I set up all users on Cloudron with a strong temporary password to do the import, and then sent them a password reset link. I'm not sure if it was really a problem but a few times I had auth issues so I decided to use a temporary password with fewer special characters.

Nextcloud

Before: Built-in NethServer option
After: Built-in Cloudron option
Steps Needed:
- Use User Migration + User Impersonation plugin to export and import all users (EXCEPT FILES)
- Copy data (however you want) into a data directory for the new Nextcloud
- Change data ownership
- Run the occ files:scan sync command using the instructions in their docs

The User Migration plugin simply could not handle the files; neither using the web UI nor the CLI. It was also very slow to generate the file backups anyway, so using rsync or something similar to migrate the files is best. If you're using external storage on your original Nextcloud, you could just attach that into the new Nextcloud and avoid copying at all.

Web Server

Before: NethServer's Virtual Host option
After: Cloudron's Surfer App
Steps Needed:
1. Copy the files in to Surfer
2. ???
3. Web Site Ready!

The UI for Surfer is way better. There's a simple web-based UI you can upload, and it has native support for API tokens to push files. Cloudron also has options for automated app-level access. Cloudron also automatically handles getting the cert for each site, where in NethServer you needed to explicitly add it to your Let's Encrypt cert.

Webmail

Before: Built-in NethServer option
After: Built-in Cloudron option
Steps Needed: Nothing special. Just install.

Video Calling

Before: Manually running Jitsi in a Docker container
After: Cloudron MiroTalk App
Steps Needed: Nothing special. Just install.

Before I had to do a lot of hacking, and even documented how for NethServer, to allow Jitsi to work with LDAP auth. After was so much easier; just install! If you want to secure it to only allow Cloudron users to host rooms you can quickly edit the configuration file.

GitLab

Before: Manually running Jitsi in a Docker container
After: Cloudron GitLab App
Steps Needed:
- Use the Direct Transfer method
- Set up a separate Container Registry app
- Configure it according to the docs
- Either re-build images or sync data from the old registry
- Set up CI/CD pipeline variables again

This one was took a while to figure out how to do (Direct Transfer), but then wasn't too bad to execute. Not as bad as Mattermost. Thankfully, the my old Docker instance of GitLab used the username as an ID for repos, as does the Coudron version. So after setting up all the users in Cloudron and importing the data the logins just worked.

The reason I had to use the direct transfer and not a backup and restore is because the version of GitLab I was running on NethServer was too old and I wasn't sure I'd be able to upgrade it to the latest version successfully since the configuration was different.

Chat

Before: NethServer Mattermost App
After: Cloudron Mattermost App
Steps Needed:
- Export data using mmctl
- Import data using mmctl
- Update the database to change the auth ID if you're using GitLab auth
- Cry that you've lost all your boards (if you're using the Boards plugin)
- Export .boardarchive files from your old boards
- Import .boardarchvie files to your new boards

I came across a few issues importing that I wrote a post about.

If you have any custom emoticons over 512 KB you'll get an ambiguous error. Fix this by replacing them with smaller versions, or delete them completely.
If you're using GitLab auth you'll need to do a database update on the users table to point it to the new numeric ID in GitLab. Even though GitLab handles all commits and project permissions just fine because it references the username, the authentication integration with Mattermost uses the integer ID. The good news is that Cloudron makes it dead simple to make database updates to any application! Just open a web app terminal, click the database button, then run some `update` statements on the `users` table.
If you're using boards, you're going to have a bad time. Next time I move servers I think I'll stop using boards with Mattermost. But if you insist you want to migrate your boards, and you want to do some extra work to at least retain assignees, then check out my post about it.

Invoicing

Before: Manually running Odoo in a Docker container
After: Cloudron Invoice Ninja App
Steps Needed:
- Manually migrate invoices

Because I had less than 50 invoices, it was easier to just learn Invoice Ninja by duplicating my customers, products, and invoices in Invoice Ninja. It's so much easier to use and snappier than Odoo.