194 lines
14 KiB
HTML
194 lines
14 KiB
HTML
|
<!doctype html>
|
||
|
|
<html lang="en-gb">
|
||
|
|
<head>
|
||
|
|
<meta charset="UTF-8" />
|
||
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
|
|
<link href="https://blog.polynom.me/css/index.css" rel="stylesheet" integrity="sha384-EJX4ZZbYMJeuoLRp93IbM/RYSzZmxw42TK7sgSRBEMChbBFK4NYUQEfsz3nBJQm8" crossorigin="anonymous" />
|
||
|
|
|
||
|
|
|
||
|
|
<link rel="alternate" type="application/rss+xml" title="blog.polynom.me Atom feed" href="https://blog.polynom.me/atom.xml">
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<meta property="og:description" content="" />
|
||
|
|
<meta property="og:title" content="Road2FOSS - My Journey to Privacy by Self-Hosting" />
|
||
|
|
<title>Road2FOSS - My Journey to Privacy by Self-Hosting</title>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="flex flex-col p-2 md:p-8 items-start md:w-4/5 mx-auto">
|
||
|
|
<!-- Header -->
|
||
|
|
<div class="flex flex-row self-center">
|
||
|
|
<img class="w-12 h-12 md:w-24 md:h-24 rounded-lg" src="https://blog.polynom.me/img/avatar.jpg" integrity="sha384-uiNteVXosQ2+o/izp41L1G9VwuwYDYCOPxzFWks058DMUhW7KfQXcipM7WqgSgEZ" alt="Profile picture" crossorigin="anonymous"/>
|
||
|
|
<div class="ml-4 self-center">
|
||
|
|
<a class="self-center text-2xl font-bold" href="/">PapaTutuWawa's Blog</a>
|
||
|
|
|
||
|
|
<ul class="list-none">
|
||
|
|
<li class="inline mr-8"><a href="/">Posts</a></li>
|
||
|
|
<li class="inline mr-8"><a href="https://blog.polynom.me/atom.xml">RSS</a></li>
|
||
|
|
<li class="inline mr-8"><a href="https://polynom.me">About</a></li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
<!-- Container for posts -->
|
||
|
|
<div class="mx-auto mt-4 w-full md:max-w-prose">
|
||
|
|
<h1 class="text-indigo-400 text-3xl">Road2FOSS - My Journey to Privacy by Self-Hosting</h1>
|
||
|
|
|
||
|
|
<span class="text-md mt-2">Posted on 2019-10-06</span>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<!-- Actual article -->
|
||
|
|
<article class="prose lg:prose-lg text-white mt-4">
|
||
|
|
<p>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.</p>
|
||
|
|
<span id="continue-reading"></span><h2 id="history">History</h2>
|
||
|
|
<p>But why do all this?</p>
|
||
|
|
<p>The answer consists of three main points, though they are weighed differently:</p>
|
||
|
|
<ol>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>Fun: I do enjoy this kind of work, so I thought it would be a fun, but quite major, side project.</li>
|
||
|
|
</ol>
|
||
|
|
<p>I knew that it would be a major undertaking but I still wanted to give it a try.</p>
|
||
|
|
<h2 id="instant-messaging">Instant Messaging</h2>
|
||
|
|
<p>Judging by the amount of personal data I leak when texting people I know I wanted to switch IM services
|
||
|
|
as quickly as possible.</p>
|
||
|
|
<p>At this stage, there were three candidates for me:</p>
|
||
|
|
<ul>
|
||
|
|
<li><em>Signal</em></li>
|
||
|
|
<li><em>Matrix</em> with Riot</li>
|
||
|
|
<li><em>Jabber/XMPP</em></li>
|
||
|
|
</ul>
|
||
|
|
<p>Originally, <em>Signal</em> 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 <em>Signal</em> 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,
|
||
|
|
<em>Signal</em>'s <em>Android</em> app has a bug which <a href="https://github.com/signalapp/Signal-Android/issues/8658">drains the phone's battery</a>
|
||
|
|
when one does not have <em>Google services</em> installed on their phone.</p>
|
||
|
|
<p><em>Matrix</em> 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 <em>Slack</em> and <em>Discord</em>, which I personally do not like
|
||
|
|
for mobile Instant Messaging. When I last looked at the entire <em>Matrix</em> 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
|
||
|
|
<em>Prosody</em>, to which I will come in the next paragraph. Moreover, I read in the the <a href="https://web.archive.org/web/20190921180013/https://disroot.org/en/blog/donating_floss"><em>Disroot blog</em></a> that they have
|
||
|
|
quite some problems with their <em>Matrix</em> homeserver as <em>"[...] [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 [...]"</em>. This
|
||
|
|
was the end for the idea of self-hosting a <em>Matrix</em> server.</p>
|
||
|
|
<p><em>Jabber/XMPP</em> 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 <em>OMEMO</em>. I also started to
|
||
|
|
appreciate federated software solutions, which made <em>Jabber</em> the clear winner for me. Tehe <em>Jabber</em> clients
|
||
|
|
that I now use on a daily basis are also very fine pieces of opensource software: <em>Conversations</em>' interface
|
||
|
|
is simple, works without draining my battery and it just works. <em>Gajim</em>, after some configuration and tweaking,
|
||
|
|
works really well, looks clean and simple and I would really love to replace <em>Discord</em> on the desktop with
|
||
|
|
<em>Gajim</em>.</p>
|
||
|
|
<p>Recently, I also started to use <em>Profanity</em>, which seems a bit rough around the edges and sometimes does not
|
||
|
|
work, but maybe I am just doing something wrong.</p>
|
||
|
|
<p>In terms of server software I initially wanted to go with <em>ejabberd</em>. But after seeing its amount of
|
||
|
|
documentation, I just chose <em>Prosody</em>. 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.</p>
|
||
|
|
<p>Since I use <em>Discord</em> 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 <em>Jabber MUC</em> using <a href="https://github.com/42wim/matterbridge"><em>matterbridge</em></a>.
|
||
|
|
Thus I can use those channels without having to have the <em>Discord</em> app installed on my devices.</p>
|
||
|
|
<p>Another use I got out of <em>Jabber</em> 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 <em>netdata</em> or for the already mentioned bridge between <em>Discord</em> and <em>Jabber</em>.</p>
|
||
|
|
<h2 id="voip">VoIP</h2>
|
||
|
|
<p>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 <em>Mumble</em>, which was a run-and-forget experience. Especially
|
||
|
|
when not using the full server but a smaller one like <em>umurmur</em>.</p>
|
||
|
|
<h2 id="code">Code</h2>
|
||
|
|
<p>At first, I used <em>Github</em>. But after <em>Microsoft</em> bought it, I was a bit sceptical and switched to <em>Gitlab</em>, 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 <em>Gitlab</em>. This includes it automatically enabling "Pipelines" when I
|
||
|
|
just created a repository even though I never enabled those.</p>
|
||
|
|
<p>That was when I came across <em>gogs</em> and <em>gitea</em>; 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.</p>
|
||
|
|
<p>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 <em>ForgeFed</em>, is being discussed on the issue tracker, though you should not quote
|
||
|
|
me on this one.</p>
|
||
|
|
<p><em>Gitea</em> was mostly a run-and-forget experience for me and is working very well.</p>
|
||
|
|
<h2 id="personal-information-management">Personal Information Management</h2>
|
||
|
|
<p>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 <em>Google</em>'s own calendar service. Then I started using <em>Disroot</em>'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.</p>
|
||
|
|
<p>After some looking around, I found <a href="https://github.com/etesync"><em>EteSync</em></a>. 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 <em>Android</em> app, in my case,
|
||
|
|
does most of the work and works really well. The only problem I had was the fact that <em>EteSync</em> has no desktop
|
||
|
|
client. They provide a web app and a server that bridges between regular DAV and <em>EteSync</em> but nothing like
|
||
|
|
a regular client.</p>
|
||
|
|
<p>Since I used regular WebDAV services, like the <em>Disroot</em> one I mentioned earlier, I have <a href="https://github.com/pimutils/vdirsyncer"><em>vdirsyncer</em></a>
|
||
|
|
installed and configured only to find out that they dropper support for <em>EteSync</em> in the last version.
|
||
|
|
Wanting a tool like <em>vdirsyncer</em> but for <em>EteSync</em> I went to work and created <a href="https://git.polynom.me/PapaTutuWawa/etesyncer"><em>etesyncer</em></a>.</p>
|
||
|
|
<h2 id="email">EMail</h2>
|
||
|
|
<p>Most of my online life I used proprietary EMail-services. Most of that time I used <em>GMail</em>. Since I bought a
|
||
|
|
domain for this project and have a server running, I thought: <em>"Why not self-host EMail?"</em>. This is exactly
|
||
|
|
what I did!</p>
|
||
|
|
<p>I use the "traditional" combination of <em>postfix</em> and <em>dovecot</em> to handle incoming, outgoing EMail and IMAP
|
||
|
|
access. Since I use <a href="https://web.archive.org/web/20190921054652/http://www.djcbsoftware.nl/code/mu/mu4e.html"><em>mu4e</em></a> in combination with <em>msmtp</em> and <em>mbsync</em> for working with email, I did not
|
||
|
|
install a webmail client.</p>
|
||
|
|
<p>This was the most difficult part to get working as the configuration sometimes worked and sometimes not.
|
||
|
|
The main culprit here was <em>DKIM</em> because it changed the permissions of its files at startup to something else
|
||
|
|
which made <em>openDKIM</em> 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 <em>DKIM</em>, <em>SPF</em> or having a <em>FQDN</em>.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>Coming from <em>Protonmail</em>, the only thing that I am missing is encryption of my EMails. Since not every person
|
||
|
|
I contact using EMail uses or knows <em>PGP</em>, 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 <em>postfix</em>, 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 <em>postfix</em>'s code and adding support for this.</p>
|
||
|
|
<h2 id="blog">Blog</h2>
|
||
|
|
<p>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 <em>Wordpress</em> 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: <em>jekyll</em> in my case.</p>
|
||
|
|
<p>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 <em>write freely</em>, I chose the staic page generator as it was much simpler. And because
|
||
|
|
I love writing in Markdown.</p>
|
||
|
|
<h2 id="webserver">Webserver</h2>
|
||
|
|
<p>Since I now use <em>GPG</em> 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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<h2 id="conclusion">Conclusion</h2>
|
||
|
|
<p>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 <em>Docker</em>
|
||
|
|
or <em>Ansible</em>. So all in all, although the project has no real end, I would say that it was and is a huge success for me.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
|
||
|
|
</article>
|
||
|
|
|
||
|
|
<!-- Common post footer -->
|
||
|
|
<div class="mt-6">
|
||
|
|
<span class="prose lg:prose-lg text-md text-white">
|
||
|
|
If you have any questions or comments, then feel free to send me an email (Preferably with GPG encryption)
|
||
|
|
to papatutuwawa [at] polynom.me or reach out to me on the Fediverse at <a href="https://social.polynom.me/papatutuwawa">@papatutuwawa@social.polynom.me</a>.
|
||
|
|
</span>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|