161 lines
11 KiB
Markdown
161 lines
11 KiB
Markdown
|
---
|
||
|
|
title: Road2FOSS - My Journey to Privacy by Self-Hosting
|
||
|
|
hashtag: road2foss
|
||
|
|
---
|
||
|
|
|
||
|
|
About one year ago, I made plans to ditch many of the proprietary services that I used
|
||
|
|
on a daily basis and replace them with FOSS alternatives. Now it is a year later and
|
||
|
|
while my project is not done, I really did quite a lot.
|
||
|
|
|
||
|
|
## History
|
||
|
|
But why do all this?
|
||
|
|
|
||
|
|
The answer consists of three main points, though they are weighed differently:
|
||
|
|
1. Privacy: The inspiration for this project came from the fact that I did not trust my messaging application back then. It was proprietary and probably collecting all the data it could, thus I wanted to get away from it.
|
||
|
|
2. Learning: I really enjoy tinkering with computer hardware, software and am quite interested in server administration. Hence, I thought it would be a greate learning opportunity for me.
|
||
|
|
3. Fun: I do enjoy this kind of work, so I thought it would be a fun, but quite major, side project.
|
||
|
|
|
||
|
|
I knew that it would be a major undertaking but I still wanted to give it a try.
|
||
|
|
|
||
|
|
## Instant Messaging
|
||
|
|
Judging by the amount of personal data I leak when texting people I know I wanted to switch IM services
|
||
|
|
as quickly as possible.
|
||
|
|
|
||
|
|
At this stage, there were three candidates for me:
|
||
|
|
- *Signal*
|
||
|
|
- *Matrix* with Riot
|
||
|
|
- *Jabber/XMPP*
|
||
|
|
|
||
|
|
Originally, *Signal* was my preferred choice since I really liked its interface. But the problem with Signal,
|
||
|
|
and I do not blame the developers for this one, is that the service only works with a mobile device running
|
||
|
|
the app. If I wanted to run *Signal* on my computer because, for example, my phone is broken or the battery
|
||
|
|
is empty, then I just could not since it requires my phone to be online. Also, which I learned only just recently,
|
||
|
|
*Signal*'s *Android* app has a bug which [drains the phone's battery](https://github.com/signalapp/Signal-Android/issues/8658)
|
||
|
|
when one does not have *Google services* installed on their phone.
|
||
|
|
|
||
|
|
*Matrix* in combination with Riot was another idea of mine. But here the problem was the mobile app. It
|
||
|
|
seemed to me more like the interface of messengers like *Slack* and *Discord*, which I personally do not like
|
||
|
|
for mobile Instant Messaging. When I last looked at the entire *Matrix* ecosystem, there was only one
|
||
|
|
well-working client for mobile, which was Riot. Additionally, the homeserver was difficult to set up; at least much more than
|
||
|
|
*Prosody*, to which I will come in the next paragraph. Moreover, I read in the the [*Disroot blog*](https://web.archive.org/web/20190921180013/https://disroot.org/en/blog/donating_floss) that they have
|
||
|
|
quite some problems with their *Matrix* homeserver as *"[...] [k]eeping room history and all metadata connected to them forever
|
||
|
|
is a terrible idea, in our opinion, and not sustainable at all. One year of history is way too much already [...]"*. This
|
||
|
|
was the end for the idea of self-hosting a *Matrix* server.
|
||
|
|
|
||
|
|
*Jabber/XMPP* being something I saw only once way back when browsing a linux forum, I became interested. It
|
||
|
|
checked all my requirements: It is cross-platform, as it is only a protocol, allows self-hosting with FOSS
|
||
|
|
software and, the most important factor, includes End-to-End-Encryption using *OMEMO*. I also started to
|
||
|
|
appreciate federated software solutions, which made *Jabber* the clear winner for me. Tehe *Jabber* clients
|
||
|
|
that I now use on a daily basis are also very fine pieces of opensource software: *Conversations*' interface
|
||
|
|
is simple, works without draining my battery and it just works. *Gajim*, after some configuration and tweaking,
|
||
|
|
works really well, looks clean and simple and I would really love to replace *Discord* on the desktop with
|
||
|
|
*Gajim*.
|
||
|
|
|
||
|
|
Recently, I also started to use *Profanity*, which seems a bit rough around the edges and sometimes does not
|
||
|
|
work, but maybe I am just doing something wrong.
|
||
|
|
|
||
|
|
In terms of server software I initially wanted to go with *ejabberd*. But after seeing its amount of
|
||
|
|
documentation, I just chose *Prosody*. It is the software that was the least painful to set up with all
|
||
|
|
requirements for modern messaging being covered by it internal or external modules. It also never crashed;
|
||
|
|
only when I messed the configuration up with syntax errors.
|
||
|
|
|
||
|
|
Since I use *Discord* and it is more difficult to bring people over from there, I went with a compromise
|
||
|
|
and started to bridge the channels I use the most to a *Jabber MUC* using [*matterbridge*](https://github.com/42wim/matterbridge).
|
||
|
|
Thus I can use those channels without having to have the *Discord* app installed on my devices.
|
||
|
|
|
||
|
|
Another use I got out of *Jabber* is the fact that I can create as many bot accounts on my server as I want. While this
|
||
|
|
sounds like I use those bots for bad things it is the opposite: I use them to tell me when something is wrong
|
||
|
|
using *netdata* or for the already mentioned bridge between *Discord* and *Jabber*.
|
||
|
|
|
||
|
|
## VoIP
|
||
|
|
VoIP is something that I use even more than plain Instant Messaging, which is why I wanted to self-host
|
||
|
|
a FOSS VoIP-solution. The most commonly used one is *Mumble*, which was a run-and-forget experience. Especially
|
||
|
|
when not using the full server but a smaller one like *umurmur*.
|
||
|
|
|
||
|
|
## Code
|
||
|
|
At first, I used *Github*. But after *Microsoft* bought it, I was a bit sceptical and switched to *Gitlab*, which
|
||
|
|
worked really well. It was even opensource so I started using it. But after some time, I found that
|
||
|
|
there are some things that annoy me with *Gitlab*. This includes it automatically enabling "Pipelines" when I
|
||
|
|
just created a repository even though I never enabled those.
|
||
|
|
|
||
|
|
That was when I came across *gogs* and *gitea*; the latter being my current solution. I wanted a simple
|
||
|
|
software that I can just run and has a somewhat nice interface. Why the nice interface? I want that if people
|
||
|
|
look at my code that it feels familiar to browse it in the browser. Also, I can invite friends to use it if
|
||
|
|
they also want to get away from proprietary services and software.
|
||
|
|
|
||
|
|
My instance has registrations disabled as I do not have the time to moderate it, but I have seen that federation
|
||
|
|
of some sorts, in the context of *ForgeFed*, is being discussed on the issue tracker, though you should not quote
|
||
|
|
me on this one.
|
||
|
|
|
||
|
|
*Gitea* was mostly a run-and-forget experience for me and is working very well.
|
||
|
|
|
||
|
|
## Personal Information Management
|
||
|
|
Since I've started to use calendars more, I wanted a solution to sync those across my devices. Before this entire
|
||
|
|
project I was using *Google*'s own calendar service. Then I started using *Disroot*'s NextCloud to synchronize
|
||
|
|
calendar data. However, it not being encrypted at rest was a concern for me as my calendar does contain some
|
||
|
|
events that I would not like an attacker to know as this would put the attacker in a position where sensitve
|
||
|
|
information can be deduced about me.
|
||
|
|
|
||
|
|
After some looking around, I found [*EteSync*](https://github.com/etesync). This software works really great, given that the server is just
|
||
|
|
a simple django app that stores data and does user management and authentication. The *Android* app, in my case,
|
||
|
|
does most of the work and works really well. The only problem I had was the fact that *EteSync* has no desktop
|
||
|
|
client. They provide a web app and a server that bridges between regular DAV and *EteSync* but nothing like
|
||
|
|
a regular client.
|
||
|
|
|
||
|
|
Since I used regular WebDAV services, like the *Disroot* one I mentioned earlier, I have [*vdirsyncer*](https://github.com/pimutils/vdirsyncer)
|
||
|
|
installed and configured only to find out that they dropper support for *EteSync* in the last version.
|
||
|
|
Wanting a tool like *vdirsyncer* but for *EteSync* I went to work and created [*etesyncer*](https://git.polynom.me/PapaTutuWawa/etesyncer).
|
||
|
|
|
||
|
|
## EMail
|
||
|
|
Most of my online life I used proprietary EMail-services. Most of that time I used *GMail*. Since I bought a
|
||
|
|
domain for this project and have a server running, I thought: *"Why not self-host EMail?"*. This is exactly
|
||
|
|
what I did!
|
||
|
|
|
||
|
|
I use the "traditional" combination of *postfix* and *dovecot* to handle incoming, outgoing EMail and IMAP
|
||
|
|
access. Since I use [*mu4e*](https://web.archive.org/web/20190921054652/http://www.djcbsoftware.nl/code/mu/mu4e.html) in combination with *msmtp* and *mbsync* for working with email, I did not
|
||
|
|
install a webmail client.
|
||
|
|
|
||
|
|
This was the most difficult part to get working as the configuration sometimes worked and sometimes not.
|
||
|
|
The main culprit here was *DKIM* because it changed the permissions of its files at startup to something else
|
||
|
|
which made *openDKIM* crash. Now it stopped doing this but I am not sure why.
|
||
|
|
What made the EMail-server so difficult was also the fact that so much goes into hosting an EMail-server I never
|
||
|
|
thought about, like *DKIM*, *SPF* or having a *FQDN*.
|
||
|
|
|
||
|
|
At this point, it pretty much runs itself. It works, it receives EMails, it sends EMails and it allows
|
||
|
|
me to view my EMails via IMAP.
|
||
|
|
|
||
|
|
Coming from *Protonmail*, the only thing that I am missing is encryption of my EMails. Since not every person
|
||
|
|
I contact using EMail uses or knows *PGP*, I would like to encrypt incoming EMails. While there are solutions
|
||
|
|
to do this, they all involve encrypting the EMail after they are put in the queue by *postfix*, which puts
|
||
|
|
them on disk. Hence, the mail was once written in plaintext. While I would like to avoid this, I have not
|
||
|
|
found a way of doing this without digging into *postfix*'s code and adding support for this.
|
||
|
|
|
||
|
|
## Blog
|
||
|
|
I wanted a blog for a long time and since I had a spare domain lying around, I decided to create one. While
|
||
|
|
I could have gone with a solution like *Wordpress* and the like, they were too complicated for my needs.
|
||
|
|
So I just went with the simplest solution which is using a static site generator: *jekyll* in my case.
|
||
|
|
|
||
|
|
This is one of the points where decentralization was a huge factor directly from the start, as this is exactly
|
||
|
|
what the web was made for, so I was actively avoiding any non-selfhost solutions. While I could have gone with
|
||
|
|
a federated solution like *write freely*, I chose the staic page generator as it was much simpler. And because
|
||
|
|
I love writing in Markdown.
|
||
|
|
|
||
|
|
## Webserver
|
||
|
|
Since I now use *GPG* to sign any emails that I send, I needed a way of exposing these keys to the public. While
|
||
|
|
I could have gone with a keyserver, I decided against it. Admittedly, I did not look into self-hosting a
|
||
|
|
keyserver but this was not my plan. I want to keep everything simple and prevent myself from installing too many
|
||
|
|
services on my server. This led me to just putting my public keys on the server and pointing my
|
||
|
|
webserver to them.
|
||
|
|
|
||
|
|
Since I run multiple services that are accessible via the browser, I needed the webserver as a reverse proxy,
|
||
|
|
pointing my different domain names to the correct services. This way, all services can run on their own ports while
|
||
|
|
the reverse proxy "unifies" them on port 443.
|
||
|
|
|
||
|
|
## Conclusion
|
||
|
|
All in all I am very happy with my setup. It allows me to host my own instances privacy-respecting software the way I like
|
||
|
|
to. It gives me something to do and allows me to learn about system administration and different tools like *Docker*
|
||
|
|
or *Ansible*. So all in all, although the project has no real end, I would say that it was and is a huge success for me.
|
||
|
|
|
||
|
|
During the course of this project, I also switched services like my search engine or the software with which I watch videos
|
||
|
|
but as I do not self-host these, I did not mention them.
|