Deploy new version bf9eadd3f6
This commit is contained in:
commit
c6f543cb4d
3
404.html
Normal file
3
404.html
Normal file
@ -0,0 +1,3 @@
|
||||
<!doctype html>
|
||||
<title>404 Not Found</title>
|
||||
<h1>404 Not Found</h1>
|
6
About-Logging.html
Normal file
6
About-Logging.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/about-logging/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/about-logging/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/about-logging/">Click here</a> to be redirected.</p>
|
6
Android-Yubikey-Signing.html
Normal file
6
Android-Yubikey-Signing.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/android-yubikey-signing/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/android-yubikey-signing/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/android-yubikey-signing/">Click here</a> to be redirected.</p>
|
6
How-I-Play-Games.html
Normal file
6
How-I-Play-Games.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/how-i-play-games/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/how-i-play-games/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/how-i-play-games/">Click here</a> to be redirected.</p>
|
6
Mainline-Hero-1.html
Normal file
6
Mainline-Hero-1.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/mainlin-hero-2/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/mainlin-hero-2/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/mainlin-hero-2/">Click here</a> to be redirected.</p>
|
6
Mainline-Hero.html
Normal file
6
Mainline-Hero.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/mainline-hero/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/mainline-hero/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/mainline-hero/">Click here</a> to be redirected.</p>
|
6
Road-to-Foss.html
Normal file
6
Road-to-Foss.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/road-to-foss/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/road-to-foss/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/road-to-foss/">Click here</a> to be redirected.</p>
|
6
Running-Prosody-traefik.html
Normal file
6
Running-Prosody-traefik.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/running-prosody-traefik/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/running-prosody-traefik/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/running-prosody-traefik/">Click here</a> to be redirected.</p>
|
6
Selfhosting-Lessons.html
Normal file
6
Selfhosting-Lessons.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/selfhosting-lessons/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/selfhosting-lessons/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/selfhosting-lessons/">Click here</a> to be redirected.</p>
|
6
Static-Site-Generator.html
Normal file
6
Static-Site-Generator.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/static-site-generator/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/static-site-generator/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/static-site-generator/">Click here</a> to be redirected.</p>
|
166
about-logging/index.html
Normal file
166
about-logging/index.html
Normal file
@ -0,0 +1,166 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="About Logging" />
|
||||
<title>About Logging</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"/>
|
||||
<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">About Logging</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2021-04-16</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p><em>TL;DR</em>: This post also talks about the problems I faced while working on my logging. To log to
|
||||
syslog from within my containers that do not support configuring a remote syslog server, I had
|
||||
<em>syslog-ng</em> expose a unix domain socket and mounted it into the container to <code>/dev/log</code>.</p>
|
||||
<span id="continue-reading"></span><h2 id="introduction">Introduction</h2>
|
||||
<p>I have written a lot of blog posts about the lessons I have learned while setting up and
|
||||
maintaining my server. But now that I started to rework my infrastructure a bit, I had to
|
||||
inevitably look at something I may have overlooked in the past: logging!</p>
|
||||
<p>Previously, I had <em>Docker</em> <em>kind of</em> manage my logs: If I needed something, I would just
|
||||
call <code>docker-compose logs <service></code> and it would spit out logs. Then, I started to
|
||||
configure my services to log to files in various locations: my <em>prosody</em> server would
|
||||
log to <code>/etc/prosody/logs/info.log</code>, my <em>nginx</em> to <code>/etc/nginx/logs/error.log</code>, etc.
|
||||
This, however, turned out to be problematic
|
||||
as, in my case, <em>prosody</em> stopped logging into the file if I rotated it with <em>logrotate</em>. It was
|
||||
also a bit impractical, as the logs were not all in the same place, but distributed across multiple
|
||||
directories.
|
||||
Moreover, <em>prosody</em> was logging things that I did not want in my logs but I could not turn off,
|
||||
like when a client connected or authenticated itself. For me, this is a problem from two perspectives:
|
||||
On the one hand, it is metadata that does not help me debug an hypothetical issue I have with my
|
||||
<em>prosody</em> installation, on the other hand, it is metadata I straight-up do not want to store.</p>
|
||||
<p>My solution was using a syslog daemon to process the logs, so that I could remove logs that I do not
|
||||
want or need, and drop them all off at <code>/var/log</code>. However, there was a problem that I faced almost
|
||||
immediately: Not all software I can configure to log to syslog, I can configure to log to a specific
|
||||
syslog server. Why is this a problem? Well, syslog does not work inside a <em>Docker</em> container out of the
|
||||
box, so I would have to have my syslog daemon expose a TCP/UDP (unix domain) socket that logs can be sent to. To
|
||||
see this issue you can try to run <code>logger -t SomeTag Hello World</code> inside one of your containers
|
||||
and try to find it, e.g. in your host's journal.</p>
|
||||
<p>Today, I found my solution to both syslog logging within the containers and filtering out unneeded logs.</p>
|
||||
<h2 id="syslog-inside-containers">Syslog inside Containers</h2>
|
||||
<p>The first step was getting the logs out of my containers without using files. To this end, I configured
|
||||
my syslog daemon - <em>syslog-ng</em> - to expose a unix domain socket to, for example, <code>/var/run/syslog</code> and
|
||||
mount it into all containers to <code>/dev/log</code>:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>source s_src {
|
||||
</span><span> system();
|
||||
</span><span> internal();
|
||||
</span><span> unix-dgram("/var/run/syslog");
|
||||
</span><span>};
|
||||
</span></code></pre>
|
||||
<p>If you now try and run <code>logger -t SomeTag Hello World</code> inside the container, you should be able
|
||||
to find "Hello World" inside the host's logs or journals.</p>
|
||||
<h2 id="ignoring-certain-logs">Ignoring Certain Logs</h2>
|
||||
<p>The next step was ignoring logs that I do not need or care about. For this, I set up two logs within
|
||||
<em>syslog-ng</em>: One that was going into my actual log file and one that was dropped:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>destination d_prosody {
|
||||
</span><span> file("/var/log/prosody.log");
|
||||
</span><span>};
|
||||
</span><span>filter f_prosody {
|
||||
</span><span> program("prosody");
|
||||
</span><span>};
|
||||
</span><span>filter f_prosody_drop {
|
||||
</span><span> program("prosody")
|
||||
</span><span> and message("(Client connected|Client disconnected|Authenticated as .*|Stream encrypted .*)$");
|
||||
</span><span>};
|
||||
</span><span>
|
||||
</span><span># Drop
|
||||
</span><span>log {
|
||||
</span><span> source(s_src);
|
||||
</span><span> filter(f_prosody_drop);
|
||||
</span><span> flags(final);
|
||||
</span><span>};
|
||||
</span><span># Log
|
||||
</span><span>log {
|
||||
</span><span> source(s_src);
|
||||
</span><span> filter(f_prosody);
|
||||
</span><span> destination(d_prosody);
|
||||
</span><span> flags(final);
|
||||
</span><span>};
|
||||
</span><span>
|
||||
</span></code></pre>
|
||||
<p>This example would log all things that <em>prosody</em> logs to the <em>prosody</em> location <code>d_prosody</code> and drop all
|
||||
lines that match the given regular expression, which, in my case, matches all lines that relate to a client
|
||||
connecting, disconnecting or authenticating.</p>
|
||||
<p>Important is the <code>flags(final);</code> in the drop rule to indicate that a log line that matches the rule should
|
||||
not be processed any further. That log also defines no destination, which tells <em>syslog-ng</em> in combination with
|
||||
the <code>final</code> flag that the log
|
||||
should be dropped.</p>
|
||||
<p>Additionally, I moved the log rule that matches everything sent to the configured source to the bottom
|
||||
of the configuration to prevent any of the logs to <em>also</em> land in the "everything" log.</p>
|
||||
<p>Since I also host a <em>Nextcloud</em> server, I was also interested in getting rid of HTTP access logs. But I would
|
||||
also like to know when someone is trying to scan my webserver for vulnerable <em>wordpress</em> installations.</p>
|
||||
<p>So I again defined rules similar to those above, but added a twist:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>filter f_nextcloud_drop {
|
||||
</span><span> program("nextcloud")
|
||||
</span><span> and match("200" value(".nextcloud.response"));
|
||||
</span><span>};
|
||||
</span><span>log {
|
||||
</span><span> source(s_src);
|
||||
</span><span> parser { apache-accesslog-parser(prefix(".nextcloud.")); };
|
||||
</span><span> filter(f_nextcloud_drop);
|
||||
</span><span> flags(final);
|
||||
</span><span>};
|
||||
</span><span>
|
||||
</span></code></pre>
|
||||
<p>As you can see, the rule for my <em>Nextcloud</em> is quite similar, except that I added a parser. With this, I can
|
||||
make <em>syslog-ng</em> understand the HTTP access log and expose its parts as variables to my filter rule. There,
|
||||
I say that my drop rule should match all access log lines that indicate a HTTP response code of 200, since
|
||||
those are locations on my server that I expect to be accessed and thus do not care about.</p>
|
||||
<h2 id="conclusion">Conclusion</h2>
|
||||
<p>With this setup, I feel much better about the logs I produce. I also have done other things not mentioned, like
|
||||
configure <em>logrotate</em> to rotate my logs daily so that my logs don't grow too large and get removed after a day.</p>
|
||||
<p>Please note that I am not an expert in <em>syslog-ng</em>. It just happend to be what I first got to do what I want. And
|
||||
the example rules I showed are also the first thing that I wrote and filtered out what I wanted.</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>
|
152
android-yubikey-signing/index.html
Normal file
152
android-yubikey-signing/index.html
Normal file
@ -0,0 +1,152 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Signing Android Apps Using a YubiKey (on NixOS)" />
|
||||
<title>Signing Android Apps Using a YubiKey (on NixOS)</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"/>
|
||||
<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">Signing Android Apps Using a YubiKey (on NixOS)</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2023-07-24</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>In my spare time, I currently develop two Android apps using <em>Flutter</em>: <a href="https://codeberg.org/PapaTutuWawa/anitrack">AniTrack</a>, a
|
||||
simple anime and manga tracker based on my own needs, and <a href="https://moxxy.org">Moxxy</a>, a modern XMPP
|
||||
client. While I don't provide release builds for AniTrack, I do for Moxxy. Those
|
||||
are signed using the key-pair that Flutter generates. I thought to myself: "Wouldn't it be cool if I could keep
|
||||
the key-pair on a separate device which does the signing for me?". The consequence
|
||||
of this thought is that I bought a <em>YubiKey 5c</em>. However, as always, using it for my
|
||||
purposes did not go without issues.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>The first issue is that the official <a href="https://developer.android.com/build/building-cmdline#deploy_from_bundle"><em>Android</em> documentation</a>
|
||||
says to use the <code>apksigner</code> tool for creating the signature. <a href="https://developers.yubico.com/PIV/Guides/Android_code_signing.html">The <em>YubiKey</em> documentation</a>, however,
|
||||
uses <code>jarsigner</code>. While I, at first, did not think much of it, <em>Android</em> has
|
||||
<a href="https://source.android.com/docs/security/features/apksigning/">different versions of the signature algorithm</a>: <code>v1</code> (what <code>jarsigner</code> does), <code>v2</code>, <code>v3</code>, <code>v3.1</code> and
|
||||
<code>v4</code>. While it seems like it would be no problem to just use <code>v1</code> signatures, <em>Flutter</em>, by default,
|
||||
generates <code>v1</code> and <code>v2</code> signatures, so I thought that I should keep it like that.</p>
|
||||
<p>So, the solution is to just use <code>apksigner</code> instead of <code>jarsigner</code>, like <a href="https://geoffreymetais.github.io/code/key-signing/">another person on the Internet</a> did.
|
||||
But that did not work for me. Running <code>apksigner</code> like that makes it complain that <code>apksigner</code> cannot
|
||||
access the required <code>sun.security.pkcs11.SunPKCS11</code> Java class.</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>> /nix/store/ib27l0593bi4ybff06ndhpb8gyhx5zfv-android-sdk-env/share/android-sdk/build-tools/34.0.0/apksigner sign \
|
||||
</span><span> --ks NONE \
|
||||
</span><span> --ks-pass "pass:<YubiKey PIN>" \
|
||||
</span><span> --provider-class sun.security.pkcs11.SunPKCS11 \
|
||||
</span><span> --provider-arg ./provider.cfg \
|
||||
</span><span> --ks-type PKCS11 \
|
||||
</span><span> --min-sdk-version 24 \
|
||||
</span><span> --max-sdk-version 34 \
|
||||
</span><span> --in unsigned.apk \
|
||||
</span><span> --out signed.apk
|
||||
</span><span>
|
||||
</span><span>Exception in thread "main" java.lang.IllegalAccessException: class com.android.apksigner.ApkSignerTool$ProviderInstallSpec cannot access class sun.security.pkcs11.SunPKCS11 (in module jdk.crypto.cryptoki) because module jdk.crypto.cryptoki does not export sun.security.pkcs11 to unnamed module @75640fdb
|
||||
</span><span> at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
|
||||
</span><span> at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
|
||||
</span><span> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:489)
|
||||
</span><span> at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
|
||||
</span><span> at com.android.apksigner.ApkSignerTool$ProviderInstallSpec.installProvider(ApkSignerTool.java:1233)
|
||||
</span><span> at com.android.apksigner.ApkSignerTool$ProviderInstallSpec.access$200(ApkSignerTool.java:1201)
|
||||
</span><span> at com.android.apksigner.ApkSignerTool.sign(ApkSignerTool.java:343)
|
||||
</span><span> at com.android.apksigner.ApkSignerTool.main(ApkSignerTool.java:92)
|
||||
</span></code></pre>
|
||||
<p>It may only be an issue because I use NixOS, as I
|
||||
cannot find another instance of someone else having this issue. But I still want my APK signed using the key-pair
|
||||
on my <em>YubiKey</em>. After a lot of trial and error, I found out that I can force Java to export certain classes
|
||||
using the <code>--add-exports</code> flag. Since <code>apksigner</code> complained that the security classes are not exported to its
|
||||
unnamed class, I had to specify <code>--add-exports sun.security.pkcs11.SunPKCS11=ALL-UNNAMED</code>.</p>
|
||||
<h2 id="my-setup">My Setup</h2>
|
||||
<p>TL;DR: I wrapped this entire setup (minus the Gradle config as that's a per-project thing) into a fancy <a href="https://codeberg.org/PapaTutuWawa/bits-and-bytes/src/branch/master/src/flutter/build.sh">script</a>.</p>
|
||||
<p>My provider configuration for the signature is exactly like the one provided in <a href="https://geoffreymetais.github.io/code/key-signing/#set-up-your-own-management-key">previously mentioned blog post</a>,
|
||||
with the difference that I cannot use the specified path to the <code>opensc-pkcs11.so</code> as I am on NixOS, where such
|
||||
paths are not used. So in my setup, I either use the Nix REPL to build the derivation for <code>opensc</code> and then
|
||||
use its <code>lib/opensc-pkcs11.so</code> path (<code>/nix/store/h2bn9iz4zqzmkmmjw9b43v30vhgillw4-opensc-0.22.0</code> in this case) for testing or, as
|
||||
used in <a href="https://codeberg.org/PapaTutuWawa/anitrack/src/branch/master/flake.nix">AniTrack</a>, let Nix figure out the path by building
|
||||
the config file from within my Nix Flake:</p>
|
||||
<pre data-lang="nix" style="background-color:#2b303b;color:#c0c5ce;" class="language-nix "><code class="language-nix" data-lang="nix"><span>{
|
||||
</span><span> </span><span style="color:#65737e;"># ...
|
||||
</span><span> </span><span style="color:#d08770;">providerArg </span><span>= </span><span style="color:#bf616a;">pkgs</span><span>.</span><span style="color:#bf616a;">writeText </span><span>"</span><span style="color:#a3be8c;">provider-arg.cfg</span><span>" ''
|
||||
</span><span style="color:#a3be8c;"> name = OpenSC-PKCS11
|
||||
</span><span style="color:#a3be8c;"> description = SunPKCS11 via OpenSC
|
||||
</span><span style="color:#a3be8c;"> library = </span><span style="font-style:italic;color:#ab7967;">${</span><span style="font-style:italic;color:#bf616a;">pkgs</span><span style="font-style:italic;color:#c0c5ce;">.</span><span style="font-style:italic;color:#bf616a;">opensc</span><span style="font-style:italic;color:#ab7967;">}</span><span style="color:#a3be8c;">/lib/opensc-pkcs11.so
|
||||
</span><span style="color:#a3be8c;"> slotListIndex = 0
|
||||
</span><span style="color:#a3be8c;"> </span><span>'';
|
||||
</span><span> </span><span style="color:#65737e;"># ...
|
||||
</span><span>}
|
||||
</span></code></pre>
|
||||
<p>Next, to force Java to export the <code>sun.security.pkcs11.SunPKCS11</code> class to <code>apksigner</code>'s unnamed class, I added <code>--add-exports sun.security.pkcs11.SunPKCS11</code>
|
||||
to the Java command line. There are two ways of doing this:</p>
|
||||
<ol>
|
||||
<li>Since <code>apksigner</code> is just a wrapper script around calling <code>apksigner.jar</code>, we could patch the wrapper script to include this parameter.</li>
|
||||
<li>Use the wrapper script's built-in mechanism to pass arguments to the <code>java</code> command.</li>
|
||||
</ol>
|
||||
<p>While option 1 would work, it would require, in my case, to override the derivation that builds my Android SDK environment, which I am not that fond of.
|
||||
Using <code>apksigner</code>'s way of specifying Java arguments (<code>-J</code>) is much easier. However, there is a little trick to it: When you pass <code>-Jsomething</code> to <code>apksigner</code>,
|
||||
the wrapper scripts transforms it to <code>java -something</code>. As such, we cannot pass <code>-Jadd-exports sun.security.pkcs11.SunPKCS11</code> because it would get transformed
|
||||
to <code>java -add-exports sun.security.[...]</code>, which is not what we want. To work around this, I quote the entire parameter to trick Bash into thinking that I'm
|
||||
passing a single argument: <code>-J"-add-exports sun.security.pkcs11.SunPKCS11"</code>. This makes the wrapper append <code>--add-exports sun.security.pkcs11.SunPKCS11</code> to the
|
||||
Java command line, ultimately allowing me to sign unsigned Android APKs with the key-pair on my <em>YubiKey</em>.</p>
|
||||
<p>Since signing a signed APK makes little sense, we also need to tell Gradle to <em>not</em> sign the APK. In the case of Flutter apps, I modified the <code>android/app/build.gradle</code>
|
||||
file to use a null signing config:</p>
|
||||
<pre data-lang="gradle" style="background-color:#2b303b;color:#c0c5ce;" class="language-gradle "><code class="language-gradle" data-lang="gradle"><span>android {
|
||||
</span><span> </span><span style="color:#65737e;">// ...
|
||||
</span><span> buildTypes {
|
||||
</span><span> release {
|
||||
</span><span> </span><span style="color:#65737e;">// This prevents Gradle from signing release builds.
|
||||
</span><span> </span><span style="color:#65737e;">// I don't care what happens to debug builds as I'm not distributing them.
|
||||
</span><span> signingConfig </span><span style="color:#d08770;">null
|
||||
</span><span> }
|
||||
</span><span> }
|
||||
</span><span>}
|
||||
</span></code></pre>
|
||||
|
||||
</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>
|
1
css/index.css
Normal file
1
css/index.css
Normal file
File diff suppressed because one or more lines are too long
149
how-i-play-games/index.html
Normal file
149
how-i-play-games/index.html
Normal file
@ -0,0 +1,149 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="How I Play Games on My Linux PC" />
|
||||
<title>How I Play Games on My Linux PC</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"/>
|
||||
<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">How I Play Games on My Linux PC</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2019-06-08</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>I love Linux. In fact, I love it so much that it runs on every computer I use, except for my phone but that
|
||||
can be changed. It always amazes me how much control Linux gives me about my computer and how easy it is
|
||||
to create a script that just does everything that I was doing manually before.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>Since Septemper of 2018, I decided to stop dual booting Windows and Linux and only use Linux. I mean, I could
|
||||
play my most played games under Linux: <em>CS:GO, Split/Second Velocity (Wine), NieR: Automata (Wine).</em> But there
|
||||
were still some games that I could not play as either have no Linux port or refuse to run with Wine. I love
|
||||
playing <em>Tom Clancy's The Division</em> and <em>The Division 2</em>. I really enjoyed playing <em>Tom Clancy's Rainbow Six Siege</em> and
|
||||
<em>Wildlands</em> was much fun. Except for <em>The Division</em>, none of these games runs under Wine. So what do?</p>
|
||||
<h1 id="gpu-passthrough">GPU Passthrough</h1>
|
||||
<p>Before even having the thought of switching to Linux "full-time", I stumbled across <a href="https://invidio.us/watch?v=16dbAUrtMX4">this video</a> by Level1Linux.
|
||||
It introduced me to the concept of hardware passthrough and I wanted to do it ever since. Now that my mainboard
|
||||
has an IOMMU and my CPU supports all needed virtualization extensions, I was ready.</p>
|
||||
<p>At that time I was using a AMD Ryzen 2400G and a Nvidia Geforce GTX 1060. I chose this particular CPU
|
||||
as it contains an iGPU, allowing me to have video output of my host even when I pass the 1060 through
|
||||
to my VM.</p>
|
||||
<!-- There are many great tutorials out there that teach you to do this thing but I was amazed at how well -->
|
||||
<!-- the games run. It should have come to no suprise but it still did. -->
|
||||
<p>The only thing that I did not like was the fact that the Nvidia driver refuses to run in a Virtual Machine, so
|
||||
I had to configure my VM via libvirt in a way that hides the fact that the driver is run inside a VM.</p>
|
||||
<h1 id="dynamic-gpu-passthrough">Dynamic GPU Passthrough</h1>
|
||||
<p>While this allowed me to play <em>The Division</em>, it was tedious to reboot to not have the GPU bound to the
|
||||
vfio-pci module so that I could use it on my host. Most guides expect you to have a second powerful GPU
|
||||
so that you don't have to worry about the unavailable GPU but to me it seemed like a waste.</p>
|
||||
<p>So I wrote myself a script which...</p>
|
||||
<ul>
|
||||
<li>unloaded all Nvidia kernel modules;</li>
|
||||
<li>started libvirt and loaded the vfio-pci module;</li>
|
||||
<li>bound the GPU to the vfio-pci module;</li>
|
||||
<li>started the VM.</li>
|
||||
</ul>
|
||||
<p>The only problem with this was that the Nvidia modules kept being loaded by the X server. This was annoying
|
||||
since I had to blacklist the modules, which prevented me from using the GPU on my host. The solution, albeit
|
||||
very hacky, was a custom package which installed the kernel modules into a new folder from where the modules
|
||||
were manually inserted using <code>insmod</code> by another script.</p>
|
||||
<p>My host's video output comes from my Ryzen's iGPU. It is not powerful enough to run games like <em>Split/Second Velocity</em>
|
||||
or <em>CS:GO</em> at an acceptable framerate, so what do?</p>
|
||||
<p>Since the Nvidia driver for Linux is proprietary <a href="https://wiki.archlinux.org/index.php/PRIME#PRIME_GPU_offloading">PRIME offloading</a> was not an option. I, however, discovered
|
||||
a library which allowed the offloading of an application's rendering - if it uses GLX - onto another GPU: <a href="https://github.com/amonakov/primus">primus</a>.</p>
|
||||
<p>It worked well enough for games that used OpenGL, like <em>CS:GO</em>. But when I tried launching <em>Split/Second Velocity</em>
|
||||
using Wine, it crashed. Vulkan offloading was not possible with primus, but with <a href="https://github.com/felixdoerre/primus_vk">primus_vk</a>. This library I never got to work so I cannot say anything about it.</p>
|
||||
<p>The only solution to that, from my point-of-view, was to create another script with launched a second X server
|
||||
on the Nvidia GPU, start Openbox as a WM on that X server and create a seamless transition from my iGPU- to my
|
||||
Nvidia-X-server using <a href="https://github.com/debauchee/barrier">barrier</a>. I then could start applications like
|
||||
Steam on the Nvidia X server and use the GPU's full potential.</p>
|
||||
<p>Since I was using barrier for the second X server I tried doing the same with barrier inside my VM and all I can
|
||||
say is that it works very well. It made the entire "workflow" with the VM much less painful as I could just take
|
||||
control of the host if I ever needed to without the need for a second keyboard.</p>
|
||||
<h1 id="gpu-changes">GPU Changes</h1>
|
||||
<p>Today, my PC runs the same AMD CPU. However, the Nvidia GPU got replaced with an AMD RX 590. This allowed me to
|
||||
use the opensource amdgpu driver, which was and still is a huge plus for me. It complicated some things for me
|
||||
though.</p>
|
||||
<p>While I can now use PRIME offloading on any application I want, I cannot simply unbind the RX 590 from the amdgpu
|
||||
driver while in X for use in my VM. While the driver exposes this functionality, it crashes the kernel as soon
|
||||
as I try to suspend or shutdown my computer.</p>
|
||||
<p>The only solution for this is to blacklist the amdgpu module when starting the kernel, bind the GPU to the vfio-pci
|
||||
driver and pass it through. Then I can load the amdgpu module again and have it attach itself to my iGPU. When I am
|
||||
done with using the VM, I can re-attach the GPU to the amdgpu driver and use it there.</p>
|
||||
<p>There are some issues with this entire setup though:</p>
|
||||
<ul>
|
||||
<li>sometimes after re-attaching, the GPU does not run with full speed. While I can normally play <em>CS:GO</em> with ~80 FPS, it can be as low as ~55 FPS after re-attachment.</li>
|
||||
<li>the GPU cannot be reset by the Linux kernel. This means that the GPU has to be disabled inside Windows before shutting down the VM. Otherwise, the amdgpu module cannot bind to the GPU which even crashed my kernel.</li>
|
||||
</ul>
|
||||
<h1 id="some-freezes">Some Freezes</h1>
|
||||
<p>Ignoring the GPU issue, since around Linux kernel 4.1x I experienced another issue: My computer would sometimes freeze
|
||||
up when opening <em>Steam</em>. In even newer versions, it even freezed by PC when I gave my VM 10GB of RAM, but did not when
|
||||
I gave my VM only 8GB.</p>
|
||||
<p>By running htop with a really small refresh interval I was lucky to observe the probable cause of these freezes: The
|
||||
kernel tried to swap as much as he could, thus making everything grind to a halt. The solution to this, even though
|
||||
it <em>feels</em> hacky, is to just tell the kernel to swap less aggressively by setting <code>vm.swappiness</code> to either a much
|
||||
lower value to swap later to to 0 to stop swapping.</p>
|
||||
<h1 id="audio">Audio</h1>
|
||||
<p>QEMU, which I used as libvirt's backend, allows you to "pass through" audio from inside the VM to your PulseAudio socket
|
||||
on the host. This worked okay-ish at first, but now - presumably because something got updated inside QEMU - it
|
||||
works well enough to play games. I get the occasional crackling but it is not distracting at all.</p>
|
||||
<p>I also tried a software called <a href="https://github.com/duncanthrax/scream">scream</a> which streamed the audio from a
|
||||
virtual audio device inside the VM to the network. As the only network interface attached to my VM was going directly
|
||||
to my host, I just set up the receiver application to listen only on this specific interface. This worked remarkebly
|
||||
well as I never heard any crackling.</p>
|
||||
<p>The only issue that I had with scream was that, for some reason, <em>Tom Clancy's The Division 2</em> would crash every 5
|
||||
minutes when I was using scream. Without it, <em>The Division 2</em> never crashed.</p>
|
||||
<h1 id="conclusion">Conclusion</h1>
|
||||
<p>My solutions are probably not the most elegant or the most practical but</p>
|
||||
<p><img src="/img/as-long-as-it-works.jpg" alt="" /></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>
|
BIN
img/as-long-as-it-works.jpg
Normal file
BIN
img/as-long-as-it-works.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 37 KiB |
BIN
img/avatar.jpg
Normal file
BIN
img/avatar.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 137 KiB |
BIN
img/serial-cable.jpg
Normal file
BIN
img/serial-cable.jpg
Normal file
Binary file not shown.
After Width: | Height: | Size: 252 KiB |
194
index.html
Normal file
194
index.html
Normal file
@ -0,0 +1,194 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="PapaTutuWawa's blog. Mainly tech stuff..." />
|
||||
<meta property="og:title" content="PapaTutuWawa's Blog" />
|
||||
<title>PapaTutuWawa's Blog</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"/>
|
||||
<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">
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/android-yubikey-signing/"><h1 class="text-indigo-400 prose prose-lg text-xl">Signing Android Apps Using a YubiKey (on NixOS)</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2023-07-24</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>In my spare time, I currently develop two Android apps using <em>Flutter</em>: <a href="https://codeberg.org/PapaTutuWawa/anitrack">AniTrack</a>, a
|
||||
simple anime and manga tracker based on my own needs, and <a href="https://moxxy.org">Moxxy</a>, a modern XMPP
|
||||
client. While I don't provide release builds for AniTrack, I do for Moxxy. Those
|
||||
are signed using the key-pair that Flutter generates. I thought to myself: "Wouldn't it be cool if I could keep
|
||||
the key-pair on a separate device which does the signing for me?". The consequence
|
||||
of this thought is that I bought a <em>YubiKey 5c</em>. However, as always, using it for my
|
||||
purposes did not go without issues.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/prosody-traefik-2/"><h1 class="text-indigo-400 prose prose-lg text-xl">Running Prosody on Port 443 Behind traefik 2: Electric ALPN</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2023-07-15</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>Hello everyone. Long time, no read.</p>
|
||||
<p>In 2020, I published a post titled "<a href="https://blog.polynom.me/Running-Prosody-traefik.html">Running Prosody on Port 443 Behind traefik</a>", where I described how I run my XMPP server
|
||||
behind the "application proxy" <a href="https://github.com/traefik/traefik"><em>traefik</em></a>.
|
||||
I did this because I wanted to run my XMPP server <em>prosody</em> on port 443, so that the clients connected
|
||||
to my server can bypass firewalls that only allow web traffic. While that approach worked,
|
||||
over the last three years I changed my setup dramatically.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/about-logging/"><h1 class="text-indigo-400 prose prose-lg text-xl">About Logging</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2021-04-16</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p><em>TL;DR</em>: This post also talks about the problems I faced while working on my logging. To log to
|
||||
syslog from within my containers that do not support configuring a remote syslog server, I had
|
||||
<em>syslog-ng</em> expose a unix domain socket and mounted it into the container to <code>/dev/log</code>.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/static-site-generator/"><h1 class="text-indigo-400 prose prose-lg text-xl">Jekyll Is Cool, But...</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2020-09-29</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>I love static site generators. They are really cool pieces of software.
|
||||
Give them some configuration files, maybe a bit of text and you receive
|
||||
a blog or a homepage. Neat!</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/running-prosody-traefik/"><h1 class="text-indigo-400 prose prose-lg text-xl">Running Prosody on Port 443 Behind traefik</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2020-02-13</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p><em>TL;DR: This post is about running prosody with HTTPS services both on port 443. If you only care about the how, then jump to</em>
|
||||
<strong>Considerations</strong> <em>and read from there.</em></p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/selfhosting-lessons/"><h1 class="text-indigo-400 prose prose-lg text-xl">Lessons Learned From Self-Hosting</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2020-01-03</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>Roughly eight months ago, according to my hosting provider, I spun up my VM which
|
||||
I use to this day to self-host my chat, my mail, my git and so on. At the beginning, I thought that
|
||||
it would allow me both to get away from proprietary software and to learn Linux administration. While
|
||||
my first goal was met without any problems, the second one I achieved in ways I did not anticipate.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/road-to-foss/"><h1 class="text-indigo-400 prose prose-lg text-xl">Road2FOSS - My Journey to Privacy by Self-Hosting</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2019-10-06</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose 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>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/mainlin-hero-2/"><h1 class="text-indigo-400 prose prose-lg text-xl">Mainline Hero Part 1 - First Attempts At Porting</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2019-08-21</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>In the first post of the series, I showed what information I gathered and what tricks can be used
|
||||
to debug our mainline port of the <em>herolte</em> kernel. While I learned a lot just by preparing for
|
||||
the actual porting, I was not able to actually get as close as to booting the kernel. I would have
|
||||
liked to write about what I did to <em>actually</em> boot a <em>5.X.X</em> kernel on the device, but instead I will tell you
|
||||
about the journey I completed thus far.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/mainline-hero/"><h1 class="text-indigo-400 prose prose-lg text-xl">Mainline Hero Part 0 - Modern Linux For My Galaxy S7</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2019-07-01</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>Ever heard of <a href="https://postmarketos.org/">PostmarketOS</a>? If not, then here's a short summary:
|
||||
PostmarketOS aims to bring <em>"[a] real Linux distribution for phones and other mobile devices [...]"</em> to,
|
||||
well, phones and other mobile devices.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
<!-- Post item -->
|
||||
<div class="flex flex-col pt-4">
|
||||
<a href="https://blog.polynom.me/how-i-play-games/"><h1 class="text-indigo-400 prose prose-lg text-xl">How I Play Games on My Linux PC</h1></a>
|
||||
<span class="text-md mt-2">Posted on 2019-06-08</span>
|
||||
|
||||
<!-- Blurp -->
|
||||
<span class="prose text-white mt-4">
|
||||
<p>I love Linux. In fact, I love it so much that it runs on every computer I use, except for my phone but that
|
||||
can be changed. It always amazes me how much control Linux gives me about my computer and how easy it is
|
||||
to create a script that just does everything that I was doing manually before.</p>
|
||||
|
||||
</span>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
19
js/MathJax/MathJax.js
vendored
Normal file
19
js/MathJax/MathJax.js
vendored
Normal file
File diff suppressed because one or more lines are too long
57
js/MathJax/config/TeX-AMS_CHTML.js
vendored
Normal file
57
js/MathJax/config/TeX-AMS_CHTML.js
vendored
Normal file
File diff suppressed because one or more lines are too long
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_AMS-Regular.woff
vendored
Normal file
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_AMS-Regular.woff
vendored
Normal file
Binary file not shown.
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Math-Italic.woff
vendored
Normal file
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Math-Italic.woff
vendored
Normal file
Binary file not shown.
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size2-Regular.woff
vendored
Normal file
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size2-Regular.woff
vendored
Normal file
Binary file not shown.
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size3-Regular.woff
vendored
Normal file
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size3-Regular.woff
vendored
Normal file
Binary file not shown.
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size4-Regular.woff
vendored
Normal file
BIN
js/MathJax/fonts/HTML-CSS/TeX/woff/MathJax_Size4-Regular.woff
vendored
Normal file
Binary file not shown.
19
js/MathJax/jax/output/CommonHTML/autoload/mtable.js
vendored
Normal file
19
js/MathJax/jax/output/CommonHTML/autoload/mtable.js
vendored
Normal file
File diff suppressed because one or more lines are too long
19
js/MathJax/jax/output/CommonHTML/fonts/TeX/AMS-Regular.js
vendored
Normal file
19
js/MathJax/jax/output/CommonHTML/fonts/TeX/AMS-Regular.js
vendored
Normal file
File diff suppressed because one or more lines are too long
19
js/MathJax/jax/output/CommonHTML/fonts/TeX/fontdata.js
vendored
Normal file
19
js/MathJax/jax/output/CommonHTML/fonts/TeX/fontdata.js
vendored
Normal file
File diff suppressed because one or more lines are too long
19
js/MathJax/jax/output/CommonHTML/jax.js
vendored
Normal file
19
js/MathJax/jax/output/CommonHTML/jax.js
vendored
Normal file
File diff suppressed because one or more lines are too long
202
mainlin-hero-2/index.html
Normal file
202
mainlin-hero-2/index.html
Normal file
@ -0,0 +1,202 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Mainline Hero Part 1 - First Attempts At Porting" />
|
||||
<title>Mainline Hero Part 1 - First Attempts At Porting</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"/>
|
||||
<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">Mainline Hero Part 1 - First Attempts At Porting</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2019-08-21</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>In the first post of the series, I showed what information I gathered and what tricks can be used
|
||||
to debug our mainline port of the <em>herolte</em> kernel. While I learned a lot just by preparing for
|
||||
the actual porting, I was not able to actually get as close as to booting the kernel. I would have
|
||||
liked to write about what I did to <em>actually</em> boot a <em>5.X.X</em> kernel on the device, but instead I will tell you
|
||||
about the journey I completed thus far.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>If you are curious about the progress I made, you can find the patches [here]({{ site.social.git_url}}/herolte-mainline). The first patches I produced are in the <code>patches/</code> directory, while the ones I created with lower
|
||||
expectations are in the <code>patches_v2/</code> directory. Both "patchsets" are based on the <code>linux-next</code> source.</p>
|
||||
<h2 id="starting-out">Starting Out</h2>
|
||||
<p>My initial expectations about mainlining were simple: <em>The kernel should at least boot and then perhaps
|
||||
crash in some way I can debug</em>.</p>
|
||||
<p>This, however, was my first mistake: Nothing is that easy! Ignoring this, I immeditately began writing
|
||||
up a <em>Device Tree</em> based on the original downstream source. This was the first big challenge as the amount of
|
||||
downstream <em>Device Tree</em> files is overwhelming:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>$ wc -l exynos* | awk -F\ '{print $1}' | awk '{sum += $1} END {print sum}'
|
||||
</span><span>54952
|
||||
</span></code></pre>
|
||||
<p>But I chewed through most of them by just looking for interesting nodes like <code>cpu</code> or <code>memory</code>, after which
|
||||
I transfered them into a new simple <em>Device Tree</em>. At this point I learned that the <em>Github</em> search does not
|
||||
work as well as I thought it does. It <strong>does</strong> find what I searched for. But only sometimes. So how to we find
|
||||
what we are looking for? By <em>grep</em>-ping through the files. Using <code>grep -i -r cpu .</code> we are able to search
|
||||
a directory tree for the keyword <code>cpu</code>. But while <em>grep</em> does a wonderful job, it is kind of slow. So at that
|
||||
point I switched over to a tool called <code>ripgrep</code> which does these searches a lot faster than plain-old grep.</p>
|
||||
<p>At some point, I found it very tiring to search for nodes; The reason being that I had to search for specific
|
||||
nodes without knowing their names or locations. This led to the creation of a script which parses a <em>Device Tree</em>
|
||||
while following includes of other <em>Device Tree</em> files, allowing me to search for nodes which have, for example, a
|
||||
certain attribute set. This script is also included in the "patch repository", however, it does not work perfectly.
|
||||
It finds most of the nodes but not all of them but was sufficient for my searches.</p>
|
||||
<p>After finally having the basic nodes in my <em>Device Tree</em>, I started to port over all of the required nodes
|
||||
to enable the serial interface on the SoC. This was the next big mistake I made: I tried to do too much
|
||||
without verifiying that the kernel even boots. This was also the point where I learned that the <em>Device Tree</em>
|
||||
by itself doesn't really do anything. It just tells the kernel how the SoC looks like so that the correct
|
||||
drivers can be loaded and initialized. So I knew that I had to port drivers from the downstream kernel into the
|
||||
mainline kernel. The kernel identifies the corresponding driver by looking at the data that the drivers
|
||||
expose.</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||||
</span><span>static struct of_device_id ext_clk_match[] __initdata = {
|
||||
</span><span> { .compatible = "samsung,exynos8890-oscclk", .data = (void *)0, },
|
||||
</span><span>};
|
||||
</span><span>[...]
|
||||
</span></code></pre>
|
||||
<p>This is an example from the <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/drivers/clk/samsung/clk-exynos8890.c#L122">clock driver</a> of the downstream kernel.
|
||||
When the kernel is processing a node of the <em>Device Tree</em> it looks for a driver that exposes the same
|
||||
compatible attribute. In this case, it would be the <em>Samsung</em> clock driver.</p>
|
||||
<p>So at this point I was wildly copying over driver code into the mainline kernel. As I forgot this during the
|
||||
porting attempt, I am
|
||||
mentioning my mistake again: I never thought about the possibility that the kernel would not boot at all.</p>
|
||||
<p>After having "ported" the driver code for the clock and some other devices I decided to try and boot the
|
||||
kernel. Having my phone plugged into the serial adapter made my terminal show nothing. So I went into the
|
||||
<em>S-Boot</em> console to poke around. There I tried some commands in the hope that the bootloader would initialize
|
||||
the hardware for me so that it magically makes the kernel boot and give me serial output. One was especially
|
||||
interesting at that time: The name made it look like it would test whether the processor can do <strong>SMP</strong> -
|
||||
<strong>S</strong>ymmetric <strong>M</strong>ulti<strong>p</strong>rocessing; <em>ARM</em>'s version of <em>Intel</em>'s <em>Hyper Threading</em> or <em>AMD</em>'s <em>SMT</em>.
|
||||
By continuing to boot, I got some output via the serial interface! It was garbage data, but it was data. This
|
||||
gave me some hope. However, it was just some data that was pushed by something other than the kernel. I checked
|
||||
this hypothesis by installing the downstream kernel, issuing the same commands and booting the kernel.</p>
|
||||
<h2 id="back-to-the-drawing-board">Back To The Drawing Board</h2>
|
||||
<p>At this point I was kind of frustrated. I knew that this endeavour was going to be difficult, but I immensely
|
||||
underestimated it.</p>
|
||||
<p>After taking a break, I went back to my computer with a new tactic: Port as few things as possible, confirm that
|
||||
it boots and then port the rest. This was inspired by the way the <em>Galaxy Nexus</em> was mainlined in
|
||||
<a href="https://postmarketos.org/blog/2019/06/23/two-years/">this</a> blog post.</p>
|
||||
<p>What did I do this time? The first step was a minimal <em>Device Tree</em>. No clock nodes. No serial nodes. No
|
||||
GPIO nodes. Just the CPU, the memory and a <em>chosen</em> node. Setting the <code>CONFIG_PANIC_TIMEOUT</code>
|
||||
<a href="https://cateee.net/lkddb/web-lkddb/PANIC_TIMEOUT.html">option</a> to 5, waiting at least 15 seconds and seeing
|
||||
no reboot, I was thinking that the phone did boot the mainline kernel. But before getting too excited, as I
|
||||
kept in mind that it was a hugely difficult endeavour, I asked in <em>postmarketOS</em>' mainline Matrix channel whether it could happen that the phone panics and still does not reboot. The answer I got
|
||||
was that it could, indeed, happen. It seems like the CPU does not know how to shut itself off. On the x86 platform, this
|
||||
is the task of <em>ACPI</em>, while on <em>ARM</em> <a href="https://linux-sunxi.org/PSCI"><em>PSCI</em></a>, the <strong>P</strong>ower <strong>S</strong>tate
|
||||
<strong>C</strong>oordination <strong>I</strong>nterface, is responsible for it. Since the mainline kernel knows about <em>PSCI</em>, I wondered
|
||||
why my phone did not reboot. As the result of some thinking I thought up 3 possibilities:</p>
|
||||
<ol>
|
||||
<li>The kernel boots just fine and does not panic. Hence no reboot.</li>
|
||||
<li>The kernel panics and wants to reboot but the <em>PSCI</em> implementation in the downstream kernel differs from the mainline code.</li>
|
||||
<li>The kernel just does not boot.</li>
|
||||
</ol>
|
||||
<p>The first possibility I threw out of the window immeditately. It was just too easy. As such, I began
|
||||
investigating the <em>PSCI</em> code. Out of curiosity, I looked at the implementation of the <code>emergency_restart</code>
|
||||
function of the kernel and discovered that the function <code>arm_pm_restart</code> is used on <em>arm64</em>. Looking deeper, I
|
||||
found out that this function is only set when the <em>Device Tree</em> contains a <em>PSCI</em> node of a supported version.
|
||||
The downstream node is compatible with version <code>0.1</code>, which does not support the <code>SYSTEM_RESET</code> functionality
|
||||
of <em>PSCI</em>. Since I could just turn off or restart the phone when using <em>Android</em> or <em>postmarketOS</em>, I knew
|
||||
that there is something that just works around old firmware.</p>
|
||||
<p>The downstream <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/arch/arm64/boot/dts/exynos8890.dtsi#L316"><em>PSCI</em> node</a> just specifies that it is compatible with <code>arm,psci</code>, so
|
||||
how do I know that it is only firmware version <code>0.1</code> and how do I know of this <code>SYSTEM_RESET</code>?</p>
|
||||
<p>If we grep for the compatible attribute <code>arm,psci</code> we find it as the value of the <code>compatible</code> field in the
|
||||
source file <code>arch/arm64/kernel/psci.c</code>. It <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/arch/arm64/kernel/psci.c#L381">specifies</a> that the exact attribute of <code>arm,psci</code>
|
||||
results in a call to the function <code>psci_0_1_init</code>. This indicates a version of <em>PSCI</em>. If we take a look
|
||||
at <em>ARM</em>'s <a href="http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf"><em>PSCI</em> documentation</a>
|
||||
we find a section called <em>"Changes in PSCIv0.2 from first proposal"</em> which contains the information that,
|
||||
compared to version 0.2, the call <code>SYSTEM_RESET</code> was added. Hence we can guess that the <em>Exynos8890</em> SoC
|
||||
comes with firmware which only supports this version 0.1 of <em>PSCI</em>.</p>
|
||||
<p>After a lot of searching, I found a node called <code>reboot</code> in the <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/arch/arm64/boot/dts/exynos8890.dtsi#L116">downstream source</a>.
|
||||
The compatible driver for it is within the <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/drivers/soc/samsung/exynos-reboot.c"><em>Samsung</em> SoC</a> driver code.</p>
|
||||
<p>Effectively, the way this code reboots the SoC, is by mapping the address of the PMU, which I guess stands for
|
||||
<em>Power Management Unit</em>, into memory and writing some value
|
||||
to it. This value is probably the command which tells the PMU to reset the SoC.
|
||||
In my "patchset" <em>patches_v2</em> I have ported this code. Testing it with the downstream kernel, it
|
||||
made the device do something. Although it crashed the kernel, it was enough to debug.</p>
|
||||
<p>To test the mainline kernel, I added an <code>emergency_restart</code> at the beginning of the <code>start_kernel</code> function.
|
||||
The result was that the device did not do anything. The only option I had left was 3; the kernel does not even
|
||||
boot.</p>
|
||||
<p>At this point I began investigating the <code>arch/arm64/</code> code of the downstream kernel more closely. However, I
|
||||
noticed something unrelated during a kernel build: The downstream kernel logs something with <em>FIPS</em> at the
|
||||
end of the build. Grepping for it resulted in some code at <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/scripts/link-vmlinux.sh#L253">the end</a> of the <code>link-vmlinuz.sh</code> script. I thought
|
||||
that it was signing the kernel with a key in the repo, but it probably is doing something else. I tested
|
||||
whether the downstream kernel boots without these crypto scripts and it did.</p>
|
||||
<p>The only thing I did not test was whether the kernel boots without
|
||||
<a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/scripts/link-vmlinux.sh#L270">"double-checking [the] jopp magic"</a>. But by looking at this script, I noticed another interesting thing:
|
||||
<code>CONFIG_RELOCATABLE_KERNEL</code>. By having just a rough idea of what this config option enables, I removed it
|
||||
from the downstream kernel and tried to boot. But the kernel did not boot. This meant that this option
|
||||
was required for booting the kernel. This was the only success I can report.</p>
|
||||
<p>By grepping for this config option I found the file <code>arch/arm64/kernel/head.S</code>. I did not know what it was
|
||||
for so I searched the internet and found a <a href="https://unix.stackexchange.com/questions/139297/what-are-the-two-head-s-files-in-linux-source">thread</a>
|
||||
on <em>StackOverflow</em> that explained that the file
|
||||
is prepended onto the kernel and executed before <code>start_kernel</code>. I mainly investigated this file, but in
|
||||
hindsight I should have also looked more at the other occurences of the <code>CONFIG_RELOCATABLE_KERNEL</code> option.</p>
|
||||
<p>So what I did was try and port over code from the downstream <code>head.S</code> into the mainline <code>head.S</code>. This is
|
||||
the point where I am at now. I did not progress any further as I am not used to assembly code or <em>ARM</em>
|
||||
assembly, but I still got some more hypotheses as to why the kernel does not boot.</p>
|
||||
<ol>
|
||||
<li>For some reason the CPU never reaches the instruction to jump to <code>start_kernel</code>.</li>
|
||||
<li>The CPU fails to initialize the MMU or some other low-level component and thus cannot jump into <code>start_kernel</code>.</li>
|
||||
</ol>
|
||||
<p>At the moment, option 2 seems the most likely as the code from the downstream kernel and the mainline kernel
|
||||
do differ some and I expect that <em>Samsung</em> added some code as their MMU might have some quirks that the
|
||||
mainline kernel does not address. However, I did not have the chance to either confirm or deny any of these
|
||||
assumptions.</p>
|
||||
<p>As a bottom line, I can say that the most useful, but in my case most ignored, thing I learned is patience.
|
||||
During the entire porting process I tried to do as much as I can in the shortest amount of time possible.
|
||||
However, I quickly realized that I got the best ideas when I was doing something completely different. As
|
||||
such, I also learned that it is incredibly useful to always have a piece of paper or a text editor handy
|
||||
to write down any ideas you might have. You never know what might be useful and what not.</p>
|
||||
<p>I also want to mention that I used the <a href="https://elixir.bootlin.com/linux/latest/source"><em>Bootlin Elixir Cross Referencer</em></a>
|
||||
a lot. It is a very useful tool to use when exploring the kernel source tree. However, I would still
|
||||
recommend to have a local copy so that you can very easily grep through the code and find things that
|
||||
neither <em>Github</em> nor <em>Elixir</em> can find.</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>
|
329
mainline-hero/index.html
Normal file
329
mainline-hero/index.html
Normal file
@ -0,0 +1,329 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Mainline Hero Part 0 - Modern Linux For My Galaxy S7" />
|
||||
<title>Mainline Hero Part 0 - Modern Linux For My Galaxy S7</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type='text/javascript' async src='https://blog.polynom.me/js/MathJax/MathJax.js?config=TeX-AMS_CHTML' integrity="sha384-3lJUsx1TJHt7BA4udB5KPnDrlkO8T6J6v/op7ui0BbCjvZ9WqV4Xm6DTP6kQ/iBH"></script>
|
||||
<script type='text/x-mathjax-config'>MathJax.Hub.Config({'CommonHTML': {scale: 100}, tex2jax: {inlineMath: [['$','$']]}});</script>
|
||||
|
||||
|
||||
</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"/>
|
||||
<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">Mainline Hero Part 0 - Modern Linux For My Galaxy S7</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2019-07-01</span>
|
||||
|
||||
|
||||
<div class="mt-6">
|
||||
<div class="prose lg:prose-lg text-md text-white">NOTE: This post uses the JavaScript library MathJax to render math equations</div>
|
||||
</div>
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>Ever heard of <a href="https://postmarketos.org/">PostmarketOS</a>? If not, then here's a short summary:
|
||||
PostmarketOS aims to bring <em>"[a] real Linux distribution for phones and other mobile devices [...]"</em> to,
|
||||
well, phones and other mobile devices.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>Ever since reading about it, I've been intrigued by the idea of running a real Linux distro
|
||||
with my UI of choice, be it <em>Plasma</em> or <em>Unity</em>, on my phone. Perhaps even running the device
|
||||
without any proprietary firmware blobs. So, I tried my best at contributing to PostmarketOS, which
|
||||
resulted in 3 MRs that have been accepted into master (Sorry for forgetting to bump the pkgver...).</p>
|
||||
<p>With this series - if I manage to not break my phone - I want to document what I, someone
|
||||
who has absolutely no idea what he is doing, learned about all this stuff, how I went about it
|
||||
and what the results are.</p>
|
||||
<h2 id="mainline-hero-0-preparations">Mainline Hero #0 - Preparations</h2>
|
||||
<p>Before I can even think about trying to make mainline Linux run on my <em>Galaxy S7</em>, we should think
|
||||
about how we can diagnose any issues that the kernel or the bootloader might have. And how do
|
||||
professionals debug? Exactly! With <strong>a lot</strong> of <code>printf()</code> statements. But how can we retrieve those
|
||||
from the device?</p>
|
||||
<h3 id="getting-output">Getting Output</h3>
|
||||
<p>While preparing myself for this task, I learned that there are a couple of ways.</p>
|
||||
<p>One is called <a href="https://wiki.postmarketos.org/wiki/Mainlining_FAQ#Writing_dmesg_to_RAM_and_reading_it_out_after_reboot"><em>RAM console</em></a>. What it does is just dump everything that the kernel prints into a
|
||||
reserved region of memory, which can later be retrieved by reading from <code>/proc/last_kmsg</code> with a
|
||||
downstream kernel. </p>
|
||||
<p>The other one is via a <a href="https://wiki.postmarketos.org/wiki/Serial_debugging">serial cable</a>. This sounded
|
||||
pretty difficult at first, the reason being that I have no idea about hardware, besides the occasional
|
||||
<strong>PC</strong> hardware talk. I imagined a cable coming out of a box, packed to the brim with electronics
|
||||
doing some black magic.</p>
|
||||
<p>The reality is - thankfully - much simpler. It is, basically, just a normal USB cable. I mean: <em>USB</em> literally
|
||||
stands for <a href="https://en.wikipedia.org/wiki/USB"><em>Universal Serial Bus</em></a>. But how come my PC does not
|
||||
read those kernel logs when I plug in my phone?</p>
|
||||
<p>As it turns out, there is a component built into my phone which decides exactly what data flows from my
|
||||
phone to the PC. Reading the <a href="https://forum.xda-developers.com/galaxy-s7/how-to/guide-samsung-galaxy-s7-uart-t3743895">XDA post</a> which the PostmarketOS Wiki linked helped understand that my
|
||||
device contains a <em>MUIC</em>, a chip which multiplexes the data lines of the USB cable towards different
|
||||
"subsystems". As I later learned, the USB standard for connectors of type Micro Type B requires 5 pins:
|
||||
power, ground, RX, TX and ID. Power and ground should be self-explanatory if you know anything
|
||||
about electronics (I don't). RX and TX are the two data lines that USB uses. As USB is just a serial
|
||||
connection, only <strong>one</strong> line is used for sending and one for receiving data. The ID line is the interesting
|
||||
one: it tells the MUIC what subsystem it should multiplex the data lines to.</p>
|
||||
<p><a href="https://web.archive.org/web/20190120234321/https://pinouts.ru/PortableDevices/micro_usb_pinout.shtml">Pinout diagram</a> of the Micro Type B connector:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span> _______________
|
||||
</span><span> / \
|
||||
</span><span>| 1 2 3 4 5 |
|
||||
</span><span>+--|--|--|--|--|--+
|
||||
</span><span> | | | | +-o Ground
|
||||
</span><span> | | | +----o ID
|
||||
</span><span> | | +-------o D+ (Data)
|
||||
</span><span> | +----------o D- (Data)
|
||||
</span><span> +-------------o VCC (Power)
|
||||
</span></code></pre>
|
||||
<p>According to the XDA post, the MUIC switches to serial - used for dumping output of the bootloader and the
|
||||
kernel - if it measures a resistance of 619kOhm attached to the ID pin. So, according to the diagram in the
|
||||
post, I built a serial cable.</p>
|
||||
<p>But how did the author of the XDA post know of the exact resistance that would tell the MUIC to switch to
|
||||
serial? If you <code>grep</code> the
|
||||
<a href="https://raw.githubusercontent.com/ivanmeler/android_kernel_samsung_herolte/lineage-15.1/arch/arm64/configs/exynos8890-herolte_defconfig"><em>S7</em>'s defconfig</a>,
|
||||
for <code>MUIC</code>, then one of the results is the KConfig flag <code>CONFIG_MUIC_UNIVERSAL_MAX77854</code>.
|
||||
If we then search the kernel tree for the keyword <code>max77854</code>, we find multiple files; one being
|
||||
<code>drivers/mfd/max77854.c</code>. This file's copyright header tells us that we deal with a <em>Maxim 77854</em> chip. Judging
|
||||
from the different files we find, it seems as if this chip is not only responsible for switching between serial
|
||||
and regular USB, but also for e.g. charging (<code>drivers/battery_v2/include/charger/max77854_charger.h</code>).</p>
|
||||
<p>However, the really interesting file is <code>drivers/muic/max77854.c</code>, since there we can find an array of structs
|
||||
that contain strings. Sounds pretty normal until you look at the strings more closely: One of the strings is
|
||||
the value <code>"Jig UART On"</code>:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||||
</span><span>#if defined(CONFIG_SEC_FACTORY)
|
||||
</span><span> {
|
||||
</span><span> .adc1k = 0x00,
|
||||
</span><span> .adcerr = 0x00,
|
||||
</span><span> .adc = ADC_JIG_UART_ON,
|
||||
</span><span> .vbvolt = VB_LOW,
|
||||
</span><span> .chgdetrun = CHGDETRUN_FALSE,
|
||||
</span><span> .chgtyp = CHGTYP_NO_VOLTAGE,
|
||||
</span><span> .control1 = CTRL1_UART,
|
||||
</span><span> .vps_name = "Jig UART On",
|
||||
</span><span> .attached_dev = ATTACHED_DEV_JIG_UART_ON_MUIC,
|
||||
</span><span> },
|
||||
</span><span>#endif /* CONFIG_SEC_FACTORY */
|
||||
</span><span>[...]
|
||||
</span></code></pre>
|
||||
<p>The keyword <code>ADC_JIG_UART_ON</code> seems especially interesting. Why? Well, the driver has to know what to do
|
||||
with each measured resistance. It would make sense that we call the constant which contains the resistance
|
||||
something like that. Additionally, it is the only constant name that does not immediately hint at its
|
||||
value or function.</p>
|
||||
<p>So we search the kernel source for this keyword. Most occurences are just
|
||||
drivers using this constant. But one hit shows its definition: <code>include/linux/muic/muic.h</code>. There we
|
||||
find on <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/b51cf88008606ebac535785ff549b9f55e5660b4/include/linux/muic/muic.h#L106">line 106</a>
|
||||
a comment which states that this constant represents a resistance of 619kOhm.</p>
|
||||
<p>To actually build the serial cable, we need to have a USB Type B male connector that we can solder our cables to.
|
||||
My first thought was to buy a simple and cheap USB Type B cable, cut it, remove the isolation and solder my
|
||||
connectors to it. I, however, failed to notice that the Type A part of the cable - the one you plug into e.g.
|
||||
your PC - only has 4 pins, while the Type B part has 5. After stumbling upon some random diagram, I learned that
|
||||
for regular USB connectivity, such as connecting your phone to your PC, the ID pin is not needed, so it is left
|
||||
disconnected. As this plan failed, I proceeded to buy a USB Type B male connector. Since I bought it on the
|
||||
Internet and the seller did not provide a diagram of what pad on the connector connects to what pin, I also
|
||||
ordered a USB Type B female breakout board.</p>
|
||||
<p>After all parts arrived, I used a digital multimeter to measure the resistance between each pad on the connector
|
||||
and on the breakout board. Since I have no idea about electronics, let me explain: Resistance is defined as
|
||||
$R = \frac{U}{I}$, where $R$ is the resistance, $U$ the voltage and $I$ the current. This means that we should
|
||||
measure - practically speaking - infinite resistance when no current is flowing and some resistance $R \gt 0$
|
||||
when we have a flowing current, meaning that we can test for continuity by attempting to measure resistance.</p>
|
||||
<p>After some poking around, I got the following diagram:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span> +---------o VCC
|
||||
</span><span> | +-----o D+
|
||||
</span><span> | | +-o GND
|
||||
</span><span> ___|___|___|___
|
||||
</span><span> / ? ? ? \
|
||||
</span><span>| ? ? |
|
||||
</span><span>+------|---|------+
|
||||
</span><span> | +---o ID
|
||||
</span><span> +-------o D-
|
||||
</span></code></pre>
|
||||
<p><img src="/img/serial-cable.jpg" alt="The "Serial Cable"" /></p>
|
||||
<p>Since the data that the serial port inside the phone is coming in using a certain protocol, which also includes
|
||||
timing, bit order and error correcting codes, we need something to convert this data into something that is
|
||||
usable on the host. Since the USB specification for data may differ from what we actually receive, we can't just
|
||||
connect the phone's D- and D+ lines to the host USB's D- and D+. Hence the need for a device which does this
|
||||
conversion for us and also deals with the timing of the data: The tiny board to which all cables lead to
|
||||
basically just contains an <em>FT232RL</em> chip from <em>FTDI</em>. It is what does all the conversion and timing magic.</p>
|
||||
<p>Since I don't want to accidentally brick by phone by frying it with 3.3V or 5V - though I think that damaging
|
||||
the hardware with 5V is pretty difficult - I did not connect the USB's 5V to the <em>FT232</em>'s VCC port.</p>
|
||||
<p>Booting up the device, we start to see data being sent via serial!</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||||
</span><span>CP Mailbox Debug
|
||||
</span><span>0x10540180 : 0xdca7b414 0x 804f99f
|
||||
</span><span>0x10540184 : 0xdeb36080 0x8112566f
|
||||
</span><span>0x10540188 : 0xf4bf0800 0x2534862d
|
||||
</span><span>0x1054018C : 0x61ff350e 0x1208fd27
|
||||
</span><span>0x10540190 : 0x17e60624 0x18121baf
|
||||
</span><span>0x105C0038 : 0x3bd58404 0x5674fb39
|
||||
</span><span>CP BL flow
|
||||
</span><span>0x10920014 : 0x79dab841 0x9b01b3fd
|
||||
</span><span>0x10800028 : 0xffbd34b1 0x9fd118cc
|
||||
</span><span>Resume el3 flow
|
||||
</span><span>EL3_VAL : 0xdcfee785 0xfbb6b0a2 0xccf99641
|
||||
</span><span>muic_register_max77854_apis
|
||||
</span><span>muic_is_max77854 chip_id:0x54 muic_id:0xb5 -> matched.
|
||||
</span><span>[MUIC] print_init_regs
|
||||
</span><span> INT:01 00 00 ST:1d 00 00 IM:00 00 00 CDET:2d 0c CTRL:1b 3b 09 b2 HVCT:00 00 LDO0:47
|
||||
</span><span>
|
||||
</span><span>MUIC rev = MAX77854(181)
|
||||
</span><span>init_multi_microusb_ic Active MUIC 0xb5
|
||||
</span><span>[...]
|
||||
</span></code></pre>
|
||||
<p>Nice! We can see what <em>SBOOT</em>, the bootloader that <em>Samsung</em> uses, tells us. But for some reason, I wasn't
|
||||
able to get into the <em>SBOOT</em> prompt to tell the kernel to dump everything via serial. While the XDA post
|
||||
used the programm <code>minicom</code>, which I could use to get <em>SBOOT</em> output, it never seemed to send the carriage
|
||||
returns while I was pressing the return key like crazy. So what I did was try to use a different tool to
|
||||
interact with the serial converter: <code>picocom</code>. And it worked! </p>
|
||||
<p>Although I set the kernel parameters to output to the TTY device <code>ttySAC4</code>, just like the XDA post said,
|
||||
I did not receive any data.</p>
|
||||
<h3 id="device-tree">Device Tree</h3>
|
||||
<p>So we can just try and boot mainline on the phone then, yes? With a very high probability: no. The reason being
|
||||
that the kernel has no idea about the actual hardware inside the phone.</p>
|
||||
<p>This may seem weird as you don't have to tell your kernel about your shiny new GPU or about your RAM. The reason
|
||||
is that your PC is designed to be modular: You can swap the CPU, the RAM and even the attached devices, like
|
||||
your GPU. This means that on X86, the CPU is able to discover its hardware since there is only one bus for
|
||||
attaching devices (ignoring RAM and the CPU): the PCI bus. How does the CPU know about its RAM?
|
||||
The RAM-modules are swappable, which means that the CPU cannot anticipate just how much RAM you
|
||||
have in your system. These information get relayed, perhaps via the MMU, to the CPU.</p>
|
||||
<p>Can't we just probe the available memory in an ARM SoC? Technically yes, but it would take a lot
|
||||
of time if we have a modern 64 bit CPU. Moreover, how do you know that a probed memory location
|
||||
is not a memory mapped device? Wouldn't it make sense to bake this data into the SoC then? Here
|
||||
again: not really. The reason is that the SoCs are vendor specific. This means that the vendor
|
||||
basically just buys the rights to put the CPU into their SoC. The rest is up to the vendor. They
|
||||
can add as much RAM as they want, without the CPU designer having much input. This means that the
|
||||
data must not be <strong>hardcoded</strong> into the CPU.</p>
|
||||
<p>On ARM and probably most other microprocessors devices can be memory mapped, which means that they respond to
|
||||
a certain region of memory being written to or read from. This makes auto-discovering devices quite difficult
|
||||
as you would have to probe <strong>a lot</strong> of memory regions.</p>
|
||||
<p>As an example: Imagine we can access 4 different locations in memory, each holding 1 byte of data. These regions
|
||||
are at the memory addresses <code>0x1</code> to <code>0x4</code>. This means that we would have to probe 4 memory locations. Easy,
|
||||
right?
|
||||
Not exactly. We would have to probe 4 times to discover 4 possible memory mapped areas with a width of 1 byte.
|
||||
If we allow a width of 2 bytes, then we would have to probe 3 different regions: <code>0x1</code>-<code>0x2</code>, <code>0x2</code>-<code>0x3</code> and
|
||||
<code>0x3</code>-<code>0x4</code>.
|
||||
This assumes that memory maps need to be directly next to each other. Otherwise we would need to use the
|
||||
binomial coefficient.</p>
|
||||
<p>This results in 10 (4x 1 byte, 3x 2 bytes, 2x 3 bytes and 1x 4 bytes) different probing attempts to discover
|
||||
possible memory mapped devices. This does not seem much when we only have a 2 bit CPU, but in the case of the
|
||||
<em>S7</em>, we have a 64 bit CPU; so we would have to probe about $\sum_{n=1}^{2^{64}} n$ times. This finite sum
|
||||
is equal (<a href="https://de.wikipedia.org/wiki/Gau%C3%9Fsche_Summenformel">German Wikipedia</a>) to
|
||||
$\frac{1}{2} 2^{64} {(2^{64} + 1)} = 1.7014 \cdot 10^{38}$. Quite a lot! Keep in mind that this
|
||||
calculation does not factor in any other busses that the SoC might use; they can, probably, use their own
|
||||
address space.</p>
|
||||
<p>So, long story short: We need to tell the kernel about all the hardware beforehand. This is where the so-called
|
||||
Device Tree comes into play. It is a structured way of describing the attached hardware. You can find examples
|
||||
in the kernel tree under <code>arch/arm{,64}/boot/dts/</code>. The problem that arises for my phone is that it
|
||||
uses the Exynos SoC from Samsung. While Exynos 7 or older would just require an addition to the already existing
|
||||
Device Tree files, the <em>S7</em> uses the Exynos 8890 SoC. This one is not in mainline, which mean that it is
|
||||
required to port it from the <a href="https://github.com/ivanmeler/android_kernel_samsung_universal8890/">downstream kernel</a> into mainline.</p>
|
||||
<h3 id="device-support">Device Support</h3>
|
||||
<p>The challenge that follows, provided I don't brick my phone, is the kernel support for the SoC's hardware.</p>
|
||||
<h4 id="gpu">GPU</h4>
|
||||
<p>The GPU of the Exynos 8890 SoC is a Mali-T880 from ARM. While there is no "official" FOSS-driver for it, one
|
||||
is in development: <a href="https://gitlab.freedesktop.org/panfrost/linux">Panfrost</a>. One of the developers once
|
||||
mentioned in PostmarketOS' Matrix channel that the driver is not ready for day-to-day use. But hopefully it
|
||||
will be in the forseeable future.</p>
|
||||
<h4 id="wifi">Wifi</h4>
|
||||
<p>While I found no data on the Exynos 8890's Wifi-chip, I managed to allow the downstream kernel to use it, albeit
|
||||
with its proprietary firmware (<a href="https://gitlab.com/postmarketOS/pmaports/merge_requests/309">MR</a>).</p>
|
||||
<p>This patch requires a patch which changes the path of the firmware in the file <code>drivers/net/wireless/bcmdhd4359/dhd.h</code>.
|
||||
The license header of <a href="https://github.com/ivanmeler/android_kernel_samsung_universal8890/blob/lineage-15.0/drivers/net/wireless/bcmdhd4359/dhd.h">said file</a>
|
||||
hints at a chip from Broadcom. The model of the chip appears to be 4359. What the <em>dhd</em> stand for? I don't know.</p>
|
||||
<p>Looking at the compatibility of the <a href="https://wireless.wiki.kernel.org/en/users/drivers/brcm80211">kernel modules</a> for Broadcom wireless chips, we can find
|
||||
that the <em>BCM4359</em> chip is compatible. But is that the same as the module folder's name specifies? Again, I don't know.
|
||||
Hopefully it is...</p>
|
||||
<h4 id="other-components">Other Components</h4>
|
||||
<p>At the time of writing this post, it has been a "long time" since I last flashed PostmarketOS on
|
||||
my phone to look at what the kernel is saying. All of this device data I gathered by looking at
|
||||
spec sheets by Samsung or the kernel. So I don't really know what other hardware is inside my
|
||||
<em>S7</em>.</p>
|
||||
<h2 id="next-steps">Next Steps</h2>
|
||||
<p>The next steps are actually testing things out and playing around with values and settings and all kinds of things.</p>
|
||||
<h2 id="other-devices-i-have-lying-around">Other Devices I Have Lying Around</h2>
|
||||
<p>This may be off-topic for the "<em>Mainline Hero</em>" series but I recently tried to find out whether another device
|
||||
I have lying around - a <em>Samsung Galaxy Note 8.0</em> - also uses such a MUIC to multiplex its USB port. While
|
||||
at first I somehow found out, which I now know is wrong, that the <em>Note 8.0</em> uses the same <em>Maxim 77854</em> as my
|
||||
<em>S7</em>, I discovered that the <em>Note 8.0</em> does use a MUIC, just not the <em>77854</em>. Since I found no other links
|
||||
talking about this, I am not sure until I test it, but what I will do is tell you about how I reached this
|
||||
conclusion!</p>
|
||||
<p>If you <code>grep</code> the <a href="https://github.com/ivanmeler/android_kernel_samsung_herolte/blob/lineage-15.1/arch/arm64/configs/exynos8890-herolte_defconfig">defconfig for the herolte</a> for
|
||||
"<em>77854</em>", then one of the results is the flag <code>CONFIG_MUIC_UNIVERSAL_MAX77854</code>. The prefix <code>CONFIG_MUIC</code> makes
|
||||
sense since this enables kernel support for the <em>Maxim 77854</em> <strong>MUIC</strong>. As such, we should be able to find
|
||||
an enabled MUIC in the <em>Note 8.0</em>'s <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/blob/lineage-16.0/arch/arm/configs/lineageos_n5110_defconfig">defconfig</a>.</p>
|
||||
<p>If we grep for <code>CONFIG_MUIC</code>, then we indeed get results. While the results do not look like the one for
|
||||
the <em>77854</em>, we get ones like <code>CONFIG_MUIC_MAX77693_SUPPORT_OTG_AUDIO_DOCK</code>. This indicates that the <em>Note 8.0</em>
|
||||
has a <em>Maxim 77693</em> MUIC built in. But it's not a very strong indicator. Since the <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/">kernel source</a> is available
|
||||
on Github, we can just search the repo for the keyword "<em>MAX77693</em>". One of the results hints at the file
|
||||
<code>drivers/misc/max77693-muic.c</code>. Looking at the Makefile of the <code>drivers/misc</code> directory, we find that this
|
||||
source file is only compiled with the KConfig flag <code>CONFIG_MFD_MAX77693</code>. Grepping the <em>Note 8.0</em>'s defconfig
|
||||
for this flag yields the result that this kernel module is enabled, hence hinting at the existence of a MUIC
|
||||
in the <em>Note 8.0</em>.</p>
|
||||
<p>If we take a closer look at the source file at <code>drivers/misc/max77693-muic.c</code>, we can find an interesting part
|
||||
at <a href="https://github.com/LineageOS/android_kernel_samsung_smdk4412/blob/b7ffe7f2aea2391737cdeac2a33217ee0ea4f2ba/drivers/misc/max77693-muic.c#L102">line 102</a>:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||||
</span><span> ADC_JIG_UART_ON = 0x1d, /* 0x11101 619K ohm */
|
||||
</span><span>[...]
|
||||
</span></code></pre>
|
||||
<p>This means that, as the <em>Maxim 77854</em> requires a 619kOhm resistor to enable UART, we can debug
|
||||
the <em>Note 8.0</em> with the same serial cable as the <em>S7</em>.</p>
|
||||
<p>Plugging it into the DIY serial cable and booting it up, we also get some output:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[...]
|
||||
</span><span>BUCK1OUT(vdd_mif) = 0x05
|
||||
</span><span>BUCK3DVS1(vdd_int) = 0x20
|
||||
</span><span>cardtype: 0x00000007
|
||||
</span><span>SB_MMC_HS_52MHZ_1_8V_3V_IO
|
||||
</span><span>mmc->card_caps: 0x00000311
|
||||
</span><span>mmc->host_caps: 0x00000311
|
||||
</span><span>[mmc] capacity = 30777344
|
||||
</span></code></pre>
|
||||
<p>Theory proven! We <strong>can</strong> also serial debug the <em>Note 8.0</em> using the same cable.</p>
|
||||
<h2 id="some-closing-words">Some Closing Words</h2>
|
||||
<p>I want to emphasize that just very few of the things I mentioned were discovered or implemented by me. I just collected
|
||||
all these information to tell you about what I learned. The only thing that I can truly say I discovered is the MR for
|
||||
the Wifi firmware...</p>
|
||||
<p>Additionally, I want to make it clear that I have no idea about microelectronics, electronics or ARM in general. All the
|
||||
things I wrote that are about ARM or electronic - especially everything in the <em>Device Tree</em> section - is pure speculation
|
||||
on my side. I never really looked into these things, but all the statements I made make sense to me. You can't just probe
|
||||
$2^{64}$ different memory addresses just to figure out how much RAM you have, can you?</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>
|
6
prosody-traefik-2.html
Normal file
6
prosody-traefik-2.html
Normal file
@ -0,0 +1,6 @@
|
||||
<!doctype html>
|
||||
<meta charset="utf-8">
|
||||
<link rel="canonical" href="https://blog.polynom.me/prosody-traefik-2/">
|
||||
<meta http-equiv="refresh" content="0; url=https://blog.polynom.me/prosody-traefik-2/">
|
||||
<title>Redirect</title>
|
||||
<p><a href="https://blog.polynom.me/prosody-traefik-2/">Click here</a> to be redirected.</p>
|
169
prosody-traefik-2/index.html
Normal file
169
prosody-traefik-2/index.html
Normal file
@ -0,0 +1,169 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Running Prosody on Port 443 Behind traefik 2: Electric ALPN" />
|
||||
<title>Running Prosody on Port 443 Behind traefik 2: Electric ALPN</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"/>
|
||||
<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">Running Prosody on Port 443 Behind traefik 2: Electric ALPN</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2023-07-15</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>Hello everyone. Long time, no read.</p>
|
||||
<p>In 2020, I published a post titled "<a href="https://blog.polynom.me/Running-Prosody-traefik.html">Running Prosody on Port 443 Behind traefik</a>", where I described how I run my XMPP server
|
||||
behind the "application proxy" <a href="https://github.com/traefik/traefik"><em>traefik</em></a>.
|
||||
I did this because I wanted to run my XMPP server <em>prosody</em> on port 443, so that the clients connected
|
||||
to my server can bypass firewalls that only allow web traffic. While that approach worked,
|
||||
over the last three years I changed my setup dramatically.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>While migrating my old server from <em>Debian</em> to <em>NixOS</em>, I decided that I wanted a website
|
||||
hosted at the same domain I host my XMPP server at. This, however, was not possible with
|
||||
<em>traefik</em> back then because it only allowed the <code>HostSNI</code> rule, which differentiates TLS
|
||||
connections using the sent <em>Server Name Indication</em>. This is a problem, because a connection
|
||||
to <code>polynom.me</code> the website and <code>polynom.me</code> the XMPP server both result in the same SNI being
|
||||
sent by a connecting client.</p>
|
||||
<p>Some time later, I stumbled upon <a href="https://github.com/yrutschle/sslh"><em>sslh</em></a>, which is a
|
||||
tool similar to <em>traefik</em> in that it allows hosting multiple services on the same port, all
|
||||
differentiated by the SNI <strong>and</strong> the ALPN set by the connecting client. ALPN, or <em>Application-Layer Protocol Negotiation</em>, is an extension
|
||||
to TLS which allows a connecting client to advertise the protocol(s) it would like to use
|
||||
inside the encrypted session <a href="https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation">(source)</a>. As such, I put
|
||||
<em>sslh</em> in front of my <em>traefik</em> and told it to route XMPP traffic (identified with an ALPN
|
||||
of <code>xmpp-client</code>) to my prosody server and everything else to my <em>traefik</em> server. While this
|
||||
worked well, there were two issues:</p>
|
||||
<ol>
|
||||
<li>I was not running <em>sslh</em> in its <a href="https://github.com/yrutschle/sslh/blob/master/doc/config.md#transparent-proxy-support">"transparent mode"</a>, which uses some fancy iptable rules to allow the services behind it to see a connecting client's real IP address instead of just <code>127.0.0.1</code>. However, this requires more setup to work. This is an issue for services which enforce rate limits, like <em>NextCloud</em> and <em>Akkoma</em>. If one of theses services gets hit by many requests, all the services see are requests from <code>127.0.0.1</code> and may thus rate limit (or ban) <code>127.0.0.1</code>, meaning that all - even legitimate - requests are rate limited. Additionally, I was not sure if I could just use this to route an incoming IPv6 request to <code>127.0.0.1</code>, which is an IPv4 address.</li>
|
||||
<li>One day, as I was updating my server, I noticed that all my web services were responding very slowly. After some looking around, it turned out that <em>sslh</em> took about 5 seconds to route IPv6 requests, but not IPv4 requests. As I did not change anything (besides update the server), to this day I am not sure what happened.</li>
|
||||
</ol>
|
||||
<p>Due to these two issues, I decided to revisit the idea I described in my old post.</p>
|
||||
<h2 id="the-prosody-setup">The Prosody Setup</h2>
|
||||
<p>On the prosody-side of things, I did not change a lot compared to the old post. I did, however,
|
||||
migrate from the <code>legacy_ssl_*</code> options to the newer <code>c2s_direct_tls_*</code> options, which
|
||||
<a href="https://hg.prosody.im/trunk/file/tip/doc/doap.xml#l758">replace the former</a>.</p>
|
||||
<p>Thus, my prosody configuration regarding direct TLS connections now looks like this:</p>
|
||||
<pre data-lang="lua" style="background-color:#2b303b;color:#c0c5ce;" class="language-lua "><code class="language-lua" data-lang="lua"><span style="color:#bf616a;">c2s_direct_tls_ports </span><span>= { </span><span style="color:#d08770;">5223 </span><span>}
|
||||
</span><span style="color:#bf616a;">c2s_direct_tls_ssl </span><span>= {
|
||||
</span><span> [</span><span style="color:#d08770;">5223</span><span>] = {
|
||||
</span><span> </span><span style="color:#a3be8c;">key </span><span>= "</span><span style="color:#a3be8c;">/etc/prosody/certs/polynom.me.key</span><span>";
|
||||
</span><span> </span><span style="color:#a3be8c;">certificate </span><span>= "</span><span style="color:#a3be8c;">/etc/prosody/certs/polynom.me.crt</span><span>";
|
||||
</span><span> };
|
||||
</span><span>}
|
||||
</span></code></pre>
|
||||
<h2 id="the-traefik-setup">The <em>Traefik</em> Setup</h2>
|
||||
<p>On <em>traefik</em>-side of things, only one thing really changed: Instead of just having a rule using
|
||||
<code>HostSNI</code>, I now also require that the connection with the XMPP server advertises an ALPN
|
||||
of <code>xmpp-client</code>, which is specified in the
|
||||
<a href="https://xmpp.org/extensions/xep-0368.html">appropriate XMPP spec</a>. From my deployment
|
||||
experience, all clients I tested (<em>Conversations</em>, <em>Blabber</em>, <em>Gajim</em>, <em>Dino</em>, <em>Monal</em>, <a href="https://moxxy.org">Moxxy</a>)
|
||||
correctly set the ALPN when connecting via a direct TLS connection.</p>
|
||||
<p>So my <em>traefik</em> configuration now looks something like this (Not really, because I let NixOS
|
||||
generate the actual config, but it is very similar):</p>
|
||||
<pre data-lang="yaml" style="background-color:#2b303b;color:#c0c5ce;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><span style="color:#bf616a;">tcp</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">routers</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">xmpps</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">https</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">rule</span><span>: "</span><span style="color:#a3be8c;">HostSNI(`polynom.me`) && ALPN(`xmpp-client`)</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">service</span><span>: </span><span style="color:#a3be8c;">prosody
|
||||
</span><span> </span><span style="color:#bf616a;">tls</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">passthrough</span><span>: </span><span style="color:#d08770;">true
|
||||
</span><span> </span><span style="color:#65737e;"># [...]
|
||||
</span><span> </span><span style="color:#bf616a;">services</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">prosody</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">loadBalancer</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">servers</span><span>:
|
||||
</span><span> - </span><span style="color:#bf616a;">address</span><span>: "</span><span style="color:#a3be8c;">127.0.0.1:5223</span><span>"
|
||||
</span><span>
|
||||
</span><span style="color:#bf616a;">http</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">routers</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">web-secure</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">https</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">rule</span><span>: "</span><span style="color:#a3be8c;">Host(`polynom.me`)</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">service</span><span>: </span><span style="color:#a3be8c;">webserver
|
||||
</span><span> </span><span style="color:#bf616a;">tls</span><span>:
|
||||
</span></code></pre>
|
||||
<p>The entrypoint <code>https</code> is just set to listen on <code>:443</code>. This way, I can route IPv4 and IPv6
|
||||
requests. Also note the <code>passthrough: true</code> in the XMPP router's <code>tls</code> settings. If this is
|
||||
not set to <code>true</code>, then <em>traefik</em> would terminate the connection's TLS session before passing
|
||||
the data to the XMPP server.</p>
|
||||
<p>However, this config has one really big issue: In order
|
||||
to have the website hosted at <code>polynom.me</code> be served using TLS, I have to set the
|
||||
router's <code>tls</code> attribute. The <em>traefik</em>
|
||||
documentation says that "<em>If both HTTP routers and TCP routers listen to the
|
||||
same entry points, the TCP routers will apply before the HTTP routers. If no matching route
|
||||
is found for the TCP routers, then the HTTP routers will take over.</em>"
|
||||
<a href="https://doc.traefik.io/traefik/routing/routers/#general_1">(source)</a>.</p>
|
||||
<p>This, however, does not seem to be the case if a HTTP router (in my example with <code>Host(`polynom.me`)</code>) and a TCP router (in my example with <code>HostSNI(`polynom.me`)</code>) respond to the same
|
||||
SNI <strong>and</strong> the HTTP router has its <code>tls</code> attribute set. In that case, the HTTP router appears
|
||||
to be checked first and will complain, if the sent ALPN is not one of the
|
||||
<a href="https://developer.mozilla.org/en-US/docs/Glossary/ALPN">HTTP ALPNs</a>, for example when
|
||||
connecting using XMPP. As such we can connect to the HTTP server but not to the
|
||||
XMPP server.</p>
|
||||
<p>It appears to be an issue that <a href="https://github.com/traefik/traefik/issues/9922">I am not alone with</a>, but also
|
||||
one that is not fixed. So I tried digging around in <em>traefik</em>'s code and tried a couple of
|
||||
things. So for my setup to work, I have to apply <a href="https://github.com/PapaTutuWawa/traefik/commit/36f0e3c805ca4e645f3313f667a6b3ff5e2fe4a9">this patch</a> to <em>traefik</em>. With that, the issue <em>appears</em>
|
||||
to be gone, and I can access both my website and my XMPP server on the same domain and on the
|
||||
same port. Do note that this patch is not upstreamed and may break things. For me, it
|
||||
works. But I haven't run extensive tests or <em>traefik</em>'s integration and unit tests.</p>
|
||||
<h2 id="conclusion">Conclusion</h2>
|
||||
<p>This approach solves problem 2 fully and problem 1 partially. <em>Traefik</em> is able to route
|
||||
the connections correctly with no delay, compared to <em>sslh</em>. It also provides my web services
|
||||
with the connecting clients' IP addresses using HTTP headers. It does not, however, provide
|
||||
my XMPP server with a connecting client's IP address. This could be solved with some clever
|
||||
trickery, like telling <em>traefik</em> to use the <a href="https://doc.traefik.io/traefik/routing/services/#proxy-protocol"><em>PROXY</em> protocol</a> when connecting to prosody,
|
||||
and enabling the <a href="https://modules.prosody.im/mod_net_proxy.html"><code>net_proxy</code></a> module. However,
|
||||
I have not yet tried such a setup, though I am very curious and may try that out.</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>
|
193
road-to-foss/index.html
Normal file
193
road-to-foss/index.html
Normal file
@ -0,0 +1,193 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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"/>
|
||||
<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>
|
4
robots.txt
Normal file
4
robots.txt
Normal file
@ -0,0 +1,4 @@
|
||||
User-agent: *
|
||||
Disallow:
|
||||
Allow: /
|
||||
Sitemap: https://blog.polynom.me/sitemap.xml
|
239
running-prosody-traefik/index.html
Normal file
239
running-prosody-traefik/index.html
Normal file
@ -0,0 +1,239 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Running Prosody on Port 443 Behind traefik" />
|
||||
<title>Running Prosody on Port 443 Behind traefik</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"/>
|
||||
<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">Running Prosody on Port 443 Behind traefik</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2020-02-13</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p><em>TL;DR: This post is about running prosody with HTTPS services both on port 443. If you only care about the how, then jump to</em>
|
||||
<strong>Considerations</strong> <em>and read from there.</em></p>
|
||||
<span id="continue-reading"></span><h1 id="introduction">Introduction</h1>
|
||||
<p>As part of my <a href="https://blog.polynom.me/Road-to-Foss.html"><em>"road to FOSS"</em></a> I
|
||||
set up my own XMPP server using <em>prosody</em>. While it has been running fine for
|
||||
quite some time, I noticed, while connected to a public Wifi, that my
|
||||
server was unreachable. At that time I was panicing because I thought prosody
|
||||
kept crashing for some reason. After using my mobile data, however, I saw
|
||||
that I <strong>could</strong> connect to my server. The only possible explanation I came
|
||||
up with is that the provider of the public Wifi is blocking anything that
|
||||
is not port 53, 80 or 443. <em>(Other ports I did not try)</em></p>
|
||||
<p>My solution: Move <em>prosody</em>'s C2S - <em>Client to Server</em> - port from 5222 to
|
||||
either port 53, 80 or 443. Port 53 did not seem like a good choice as I
|
||||
want to keep myself the possibilty of hosting a DNS server. So the only
|
||||
choice was between 80 and 443.</p>
|
||||
<h1 id="considerations">Considerations</h1>
|
||||
<p>Initially I went with port 80 because it would be the safest bet: You cannot
|
||||
block port 80 while still allowing customers to access the web. This would
|
||||
have probably worked out, but I changed it to port 443 later-on. The reason
|
||||
being that I need port 80 for Let's Encrypt challenges. Since I use nginx
|
||||
as a reverse proxy for most of my services, I thought that I can multiplex
|
||||
port 80 between LE and <em>prosody</em>. This was not possible with nginx.</p>
|
||||
<p>So I discoverd traefik since it allows such a feat. The only problem is that
|
||||
it can only route TCP connections based on the
|
||||
<a href="https://github.com/containous/traefik/blob/master/docs/content/routing/routers/index.md#rule-1">SNI</a>. This requires the
|
||||
XMPP connection to be encrypted entirely, not after STARTTLS negotiation,
|
||||
which means that I would have to configure <em>prosody</em> to allow such a
|
||||
connection and not offer STARTTLS.</p>
|
||||
<h1 id="prosody">Prosody</h1>
|
||||
<p>Prosody has in its documentation no mentions of <em>direct TLS</em> which made me
|
||||
guess that there is no support for it in <em>prosody</em>. After, however, asking
|
||||
in the support group, I was told that this feature is called <em>legacy_ssl</em>.</p>
|
||||
<p>As such, one only has to add</p>
|
||||
<pre data-lang="lua" style="background-color:#2b303b;color:#c0c5ce;" class="language-lua "><code class="language-lua" data-lang="lua"><span style="color:#65737e;">-- [...]
|
||||
</span><span>
|
||||
</span><span style="color:#bf616a;">legacy_ssl_ports </span><span>= { </span><span style="color:#d08770;">5223 </span><span>}
|
||||
</span><span style="color:#bf616a;">legacy_ssl_ssl </span><span>= {
|
||||
</span><span> [</span><span style="color:#d08770;">5223</span><span>] = {
|
||||
</span><span> </span><span style="color:#a3be8c;">key </span><span>= "</span><span style="color:#a3be8c;">/path/to/keyfile</span><span>";
|
||||
</span><span> </span><span style="color:#a3be8c;">certificate </span><span>= "</span><span style="color:#a3be8c;">/path/to/certificate</span><span>";
|
||||
</span><span> }
|
||||
</span><span>}
|
||||
</span><span>
|
||||
</span><span style="color:#65737e;">-- [...]
|
||||
</span></code></pre>
|
||||
<p><em>Note:</em> In my testing, <em>prosody</em> would not enable <em>legacy_ssl</em> unless I
|
||||
explicitly set <code>legacy_ssl_ports</code>.</p>
|
||||
<p>When <em>prosody</em> tells you that it enabled <code>legacy_ssl</code> on the specified
|
||||
ports, then you can test the connection by using OpenSSL to connect to it:
|
||||
<code>openssl s_client -connect your.domain.example:5223</code>. OpenSSL should tell
|
||||
you the data it can get from your certificate.</p>
|
||||
<h1 id="traefik">traefik</h1>
|
||||
<p>In my configuration, I run <em>prosody</em> in an internal <em>Docker</em> network. In
|
||||
order to connect it, in my case port 5223, to the world via port 443, I
|
||||
configured my traefik to distinguish between HTTPS and XMPPS connections
|
||||
based on the set SNI of the connection.</p>
|
||||
<p>To do so, I firstly configured the static configuration to have
|
||||
port 443 as an entrypoint:</p>
|
||||
<pre data-lang="yaml" style="background-color:#2b303b;color:#c0c5ce;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><span style="color:#65737e;"># [...]
|
||||
</span><span>
|
||||
</span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">https</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">address</span><span>: "</span><span style="color:#a3be8c;">:443</span><span>"
|
||||
</span><span>
|
||||
</span><span style="color:#65737e;"># [...]
|
||||
</span></code></pre>
|
||||
<p>For the dynamic configuration, I add two routers - one for TCP, one for
|
||||
HTTPS - that both listen on the entrypoint <code>https</code>. As the documentation
|
||||
<a href="https://github.com/containous/traefik/blob/master/docs/content/routing/routers/index.md#general-1">says</a>,
|
||||
<em>"If both HTTP routers and TCP routers listen to the same entry points, the TCP routers will apply before the HTTP routers."</em>. This means that traefik has
|
||||
to distinguish the two somehow.</p>
|
||||
<p>We do this by using the <code>Host</code> rule for the HTTP router and <code>HostSNI</code> for
|
||||
the TCP router.</p>
|
||||
<p>As such, the dynamic configuration looks like this:</p>
|
||||
<pre data-lang="yaml" style="background-color:#2b303b;color:#c0c5ce;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><span style="color:#bf616a;">tcp</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">routers</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">xmpps</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">https</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">rule</span><span>: "</span><span style="color:#a3be8c;">HostSNI(`xmpps.your.domain.example`)</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">service</span><span>: </span><span style="color:#a3be8c;">prosody-dtls
|
||||
</span><span> </span><span style="color:#bf616a;">tls</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">passthrough</span><span>: </span><span style="color:#d08770;">true
|
||||
</span><span> </span><span style="color:#65737e;"># [...]
|
||||
</span><span> </span><span style="color:#bf616a;">services</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">prosody-dtls</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">loadBalancer</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">servers</span><span>:
|
||||
</span><span> - </span><span style="color:#bf616a;">address</span><span>: "</span><span style="color:#a3be8c;"><IP>:5223</span><span>"
|
||||
</span><span>
|
||||
</span><span style="color:#bf616a;">http</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">routers</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">web-secure</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">https</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">rule</span><span>: "</span><span style="color:#a3be8c;">Host(`web.your.domain.example`)</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">service</span><span>: </span><span style="color:#a3be8c;">webserver
|
||||
</span></code></pre>
|
||||
<p>It is important to note here, that the option <code>passthrough</code> has to be <code>true</code>
|
||||
for the TCP router as otherwise the TLS connection would be terminated by
|
||||
traefik.</p>
|
||||
<p>Of course, you can instruct prosody to use port 443 directly, but I prefer
|
||||
to keep it like this so I can easily see which connection goes to where.</p>
|
||||
<h1 id="http-upload">HTTP Upload</h1>
|
||||
<p>HTTP Upload was a very simple to implement this way. Just add another HTTPS
|
||||
route in the dynamic traefik configuration to either the HTTP port of
|
||||
prosody, which would terminate the TLS connection from traefik onwards, or
|
||||
the HTTPS port, which - if running traefik and prosody on the same host -
|
||||
would lead to a possible unnecessary re-encryption of the data.</p>
|
||||
<p>This means that prosody's configuration looks like this:</p>
|
||||
<pre data-lang="lua" style="background-color:#2b303b;color:#c0c5ce;" class="language-lua "><code class="language-lua" data-lang="lua"><span>[</span><span style="color:#d08770;">...</span><span>]
|
||||
</span><span style="color:#65737e;">-- Perhaps just one is enough
|
||||
</span><span style="color:#bf616a;">http_ports </span><span>= { </span><span style="color:#d08770;">5280 </span><span>}
|
||||
</span><span style="color:#bf616a;">https_ports </span><span>= { </span><span style="color:#d08770;">5281 </span><span>}
|
||||
</span><span>
|
||||
</span><span style="color:#bf616a;">Component </span><span>"</span><span style="color:#a3be8c;">your.domain</span><span>"
|
||||
</span><span> </span><span style="color:#65737e;">-- Perhaps just one is required, but I prefer to play it safe
|
||||
</span><span> </span><span style="color:#bf616a;">http_external_url </span><span>= "</span><span style="color:#a3be8c;">https://http.xmpp.your.domain</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">http_host </span><span>= "</span><span style="color:#a3be8c;">http.xmpp.your.domain</span><span>"
|
||||
</span><span>[</span><span style="color:#d08770;">...</span><span>]
|
||||
</span></code></pre>
|
||||
<p>And traefik's like this:</p>
|
||||
<pre data-lang="yaml" style="background-color:#2b303b;color:#c0c5ce;" class="language-yaml "><code class="language-yaml" data-lang="yaml"><span>[</span><span style="color:#d08770;">...</span><span>]
|
||||
</span><span style="color:#bf616a;">http</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">routers</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">prosody-https</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">entrypoints</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">https</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">rule</span><span>: "</span><span style="color:#a3be8c;">Host(`http.xmpp.your.domain`)</span><span>"
|
||||
</span><span> </span><span style="color:#bf616a;">service</span><span>: </span><span style="color:#a3be8c;">prosody-http
|
||||
</span><span>
|
||||
</span><span> </span><span style="color:#bf616a;">services</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">prosody-http</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">loadBalancer</span><span>:
|
||||
</span><span> </span><span style="color:#bf616a;">servers</span><span>:
|
||||
</span><span> - "</span><span style="color:#a3be8c;">http://prosody-ip:5280</span><span>"
|
||||
</span><span>[</span><span style="color:#d08770;">...</span><span>]
|
||||
</span></code></pre>
|
||||
<h1 id="dns">DNS</h1>
|
||||
<p>In order for clients to pick this change up, one has to create a DNS SRV
|
||||
record conforming to <a href="https://xmpp.org/extensions/xep-0368.html">XEP-0368</a>.</p>
|
||||
<p>This change takes some time until it reaches the clients, so it would be wise
|
||||
to keep the regular STARTTLS port 5222 open and connected to prosody until
|
||||
the DNS entry has propagated to all DNS servers.</p>
|
||||
<h1 id="caveats">Caveats</h1>
|
||||
<p>Of course, there is nothing without some caveats; some do apply here.</p>
|
||||
<p>This change does not neccessarilly get applied to all clients automatically.
|
||||
Clients like <em>Conversations</em> and its derivatives, however, do that when they
|
||||
are reconnecting. Note that there may be clients that do not support XEP-0368
|
||||
which will not apply this change automatically, like - at least in my
|
||||
testing - <em>profanity</em>.</p>
|
||||
<p>Also there may be some clients that do not support <em>direct TLS</em> and thus
|
||||
cannot connect to the server. In my case, <em>matterbridge</em> was unable to
|
||||
connect as it, without further investigation, can only connect with either
|
||||
no TLS or with STARTTLS.</p>
|
||||
<h1 id="conclusion">Conclusion</h1>
|
||||
<p>In my case, I run my <em>prosody</em> server like this:</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span> <<WORLD>>-------------+
|
||||
</span><span> | |
|
||||
</span><span> [traefik]-------------/|/--------------+
|
||||
</span><span> | | |
|
||||
</span><span> {xmpp.your.domain} [5269] {other.your.domain}
|
||||
</span><span> [443 -> 5223] | [443 -> 80]
|
||||
</span><span>{http.xmpp.your.domain} | |
|
||||
</span><span> [443 -> 5280] | |
|
||||
</span><span> | | |
|
||||
</span><span> [prosody]-------------+ [nginx]
|
||||
</span></code></pre>
|
||||
<p>As I had a different port for <em>prosody</em> initially (80), I had to wait until
|
||||
the DNS records are no longer cached by other DNS servers or clients. This
|
||||
meant waiting for the TTL of the record, which in my case were 18000 seconds,
|
||||
or 5 hours.</p>
|
||||
<p>The port 5222 is, in my case, not reachable from the outside world but via my
|
||||
internal <em>Docker</em> compose network so that my <em>matterbridge</em> bridges still work.</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>
|
144
selfhosting-lessons/index.html
Normal file
144
selfhosting-lessons/index.html
Normal file
@ -0,0 +1,144 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Lessons Learned From Self-Hosting" />
|
||||
<title>Lessons Learned From 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"/>
|
||||
<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">Lessons Learned From Self-Hosting</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2020-01-03</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>Roughly eight months ago, according to my hosting provider, I spun up my VM which
|
||||
I use to this day to self-host my chat, my mail, my git and so on. At the beginning, I thought that
|
||||
it would allow me both to get away from proprietary software and to learn Linux administration. While
|
||||
my first goal was met without any problems, the second one I achieved in ways I did not anticipate.</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>During these eight months, I learned quite a lot. Not by reading documentation, but by messing up
|
||||
deployments. So this post is my telling of how I messed up and what lessons I learned from it.</p>
|
||||
<h1 id="lesson-1-document-everything">Lesson 1: Document everything</h1>
|
||||
<p>I always tell people that you should document your code. When asked why I answer that you won't
|
||||
remember what that line does when you have not looked at your codebase for weeks or months.</p>
|
||||
<p>What I did not realise is that this also applies to administration. I only wrote basic documentation
|
||||
like a howto for certificate generation or a small troubleshooting guide. This, however, missed the most
|
||||
important thing to document: the entire infrastructure.</p>
|
||||
<p>Whenever I needed to look up my port mapping, what did I do? I opened up my <em>Docker compose</em> configuration
|
||||
and search for the port mappings. What did I do when I wanted to know what services I have? Open my
|
||||
<em>nginx</em> configuration and search for <code>server</code> directives.</p>
|
||||
<p>This is a very slow process since I have to remember what services I have behind a reverse proxy and which
|
||||
ones I have simply exposed. This lead me in the end to creating a folder - called <code>docs</code> - in which
|
||||
I document everything. What certificates are used by what and where they are, port mappings, a graph
|
||||
showing the dependencies of my services, ... While it may be tedious to create at first, it will really
|
||||
help.</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span>[World]
|
||||
</span><span>+
|
||||
</span><span>|
|
||||
</span><span>+-[443]-[nginx]-+-(blog.polynom.me)
|
||||
</span><span> +-(git.polynom.me)-[gitea]
|
||||
</span></code></pre>
|
||||
<p>Above, you can see an excerpt from my <em>"network graph"</em>.</p>
|
||||
<h1 id="lesson-2-version-control-everything">Lesson 2: Version Control everything</h1>
|
||||
<p>Version Control Systems are a great thing. Want to try something out? Branch, try out and then either
|
||||
merge back or roll back. Want to find out what changes broke something? Diff the last revisions and narrow
|
||||
down your "search space". Want to know what you did? View the log.</p>
|
||||
<p>While it might seem unneccessary, it helps me keep my cool, knowing that if I ever mess up my configuration, I
|
||||
can just roll back the configuration from within git.</p>
|
||||
<h1 id="lesson-3-have-a-test-environment">Lesson 3: Have a test environment</h1>
|
||||
<p>While I was out once, I connected to a public Wifi. There, however, I could not connect to my VPN. It simply
|
||||
did not work. A bit later, my Jabber client <em>Conversations</em> told me that it could not find my server. After
|
||||
some thinking, I came to the conclusion that the provider of said public Wifi was probably blocking port <code>5222</code>
|
||||
<em>(XMPP Client-to-Server)</em> and whatever port the VPN is using. As such, I wanted to change the port my
|
||||
Jabber server uses. Since I do not have a failover server I tried testing things out locally, but gave up
|
||||
after some time and just went and "tested in production". Needless to say that this was a bad idea. At first,
|
||||
<em>Conversations</em> did not do a DNS lookup to see the changed XMPP port, which lead me to removing the DNS entry.
|
||||
However, after some time - probably after the DNS change propagated far enough - <em>Conversations</em> said that it
|
||||
could not find the server, even though it was listening on port <code>5222</code>. Testing with the new port yieled
|
||||
success.</p>
|
||||
<p>This experience was terrible for me. Not only was it possible that I broke my Jabber server, but it would
|
||||
annoy everyone I got to install a Jabber client to talk to me as it would display <em>"Cannot connect to..."</em>.
|
||||
If I had tested this locally, I probably would have been much calmer. In the end, I nervously watched as everyone
|
||||
gradually reconnected...</p>
|
||||
<h1 id="lesson-4-use-tools-and-write-scripts">Lesson 4: Use tools and write scripts</h1>
|
||||
<p>The first server I ever got I provisioned manually. I mean, back then it made sense: It was a one-time provisioning and nothing should
|
||||
change after the initial deployment. But now that I have a continually evolving server, I somehow need to document every step in case
|
||||
I ever need to provision the same server again.</p>
|
||||
<p>In my case it is <em>Ansible</em>. In my playbook I keep all the roles, e.g. <em>nginx</em>, <em>matterbridge</em>, <em>prosody</em>, separate and apply them to my one
|
||||
server. In there I also made <strong>heavy</strong> use of templates. The reason for it is that before I started my <a href="https://blog.polynom.me/Road-to-Foss.html"><em>"Road to FOSS"</em></a>
|
||||
I used a different domain that I had lying around. Changing the domain name manually would have been a very tedious process, so I decided to use
|
||||
templates from the get-go. To make my life easier in case I ever change domains again, I defined all my domain names based on my <code>domain</code> variable.
|
||||
The domain for git is defined as {% raw %}<code>git.{{ domain }}</code>{% endraw %}, the blog one as {% raw %}<code>blog.{{ domain }}</code>{% endraw %}.
|
||||
Additionally, I make use of <em>Ansible Vaults</em>, allowing me to have encrypted secrets in my playbook.</p>
|
||||
<p>During another project, I also set up an <em>Ansible</em> playbook. There, however, I did not use templates. I templated the configuration files using a Makefile
|
||||
that was calling <code>sed</code> to replace the patterns. Not only was that a fragile method, it was also unneeded as <em>Ansible</em> was already providing
|
||||
this functionality for me. I was just wasting my own time.</p>
|
||||
<p>What I also learned was that one <em>Ansible</em> playbook is not enough. While it is nice to automatically provision a server using <em>Ansible</em>, there are other things
|
||||
that need to be done. Certificates don't rotate themselves. From that, I derived a rule stating that if a task needs to be done more than once, then it is
|
||||
time to write a script for it.</p>
|
||||
<h1 id="lesson-4-1-automate">Lesson 4.1: Automate</h1>
|
||||
<p>Closely tied to the last point: If a task needs to be performed, then you should consider creating a cronjob, or a systemd timer if that is more your thing,
|
||||
to automatically run it. You don't want to enjoy your day, only for it to be ruined by an expired certificate causing issues.</p>
|
||||
<p>Since automated cronjobs can cause trouble aswell, I decided to run all automated tasks on days at a time during which I am like to be able to react. As such, it is very
|
||||
important to notify yourself of those automated actions. My certificate rotation, for example, sends me an eMail at the end, telling me if the certificates
|
||||
were successfully rotated and if not, which ones failed. For those cases, I also keep a log of the rotation process somewhere else so that I can review it.</p>
|
||||
<h1 id="lesson-5-unexpected-things-happen">Lesson 5: Unexpected things happen</h1>
|
||||
<p>After having my shiny server run for some time, I was happy. It was basically running itself. Until <em>Conversations</em> was unable to contact my server,
|
||||
connected to a public Wifi. This is something that I did not anticipate, but happened nevertheless.</p>
|
||||
<p>This means that my deployment was not a run-and-forget solution but a constantly evolving system, where small improvements are periodically added.</p>
|
||||
<h1 id="conclusion">Conclusion</h1>
|
||||
<p>I thought I would just write down my thoughts on all the things that went wrong over the course of my self-hosting adventure. They may not
|
||||
be best practices, but things that really helped me a lot.</p>
|
||||
<p>Was the entire process difficult? At first. Was the experience an opportunity to learn? Absolutely! Was it fun? Definitely.</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>
|
46
sitemap.xml
Normal file
46
sitemap.xml
Normal file
@ -0,0 +1,46 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/</loc>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/about-logging/</loc>
|
||||
<lastmod>2021-04-16</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/android-yubikey-signing/</loc>
|
||||
<lastmod>2023-07-24</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/how-i-play-games/</loc>
|
||||
<lastmod>2019-06-08</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/mainlin-hero-2/</loc>
|
||||
<lastmod>2019-08-21</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/mainline-hero/</loc>
|
||||
<lastmod>2019-07-01</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/prosody-traefik-2/</loc>
|
||||
<lastmod>2023-07-15</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/road-to-foss/</loc>
|
||||
<lastmod>2019-10-06</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/running-prosody-traefik/</loc>
|
||||
<lastmod>2020-02-13</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/selfhosting-lessons/</loc>
|
||||
<lastmod>2020-01-03</lastmod>
|
||||
</url>
|
||||
<url>
|
||||
<loc>https://blog.polynom.me/static-site-generator/</loc>
|
||||
<lastmod>2020-09-29</lastmod>
|
||||
</url>
|
||||
</urlset>
|
203
static-site-generator/index.html
Normal file
203
static-site-generator/index.html
Normal file
@ -0,0 +1,203 @@
|
||||
<!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" />
|
||||
|
||||
|
||||
<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="Jekyll Is Cool, But..." />
|
||||
<title>Jekyll Is Cool, But...</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"/>
|
||||
<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">Jekyll Is Cool, But...</h1>
|
||||
|
||||
<span class="text-md mt-2">Posted on 2020-09-29</span>
|
||||
|
||||
|
||||
|
||||
<!-- Actual article -->
|
||||
<article class="prose lg:prose-lg text-white mt-4">
|
||||
<p>I love static site generators. They are really cool pieces of software.
|
||||
Give them some configuration files, maybe a bit of text and you receive
|
||||
a blog or a homepage. Neat!</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>For a long time, I have been using <a href="https://github.com/jekyll/jekyll"><em>Jekyll</em></a>
|
||||
as my static site generator of choice. Mostly, because it is one of the
|
||||
most famous ones out there and thus there are tons of plugins, documentation
|
||||
and templates to get started. It was nice, until I wished it would do
|
||||
a bit more...</p>
|
||||
<p>During some time off, I wanted to do an overhaul of my infrastructure. Make
|
||||
things cleaner, document more things and finally do those tasks that I have
|
||||
been pushing aside for quite some time. One of those things is to make all
|
||||
my webpages, which today only include <a href="https://git.polynom.me/PapaTutuWawa/blog.polynom.me">this blog</a>
|
||||
and my <a href="https://git.polynom.me/polynom.me/xmpp-invite-web">XMPP invite page</a>,
|
||||
share common assets. This got started after I wrote the invitation page
|
||||
and thought that it looked pretty good.</p>
|
||||
<p>So off I went to create a subdomain for my own "CDN", generate a TLS
|
||||
certificate and... I got stuck. I wanted to have <em>Jekyll</em> generate two
|
||||
seperate versions of my pages for me depending on what I wanted to do:
|
||||
One with local assets for local previewing and testing and one with my
|
||||
"CDN" attached. As such I would have liked to have three files: <code>_config.dev.yml</code>,
|
||||
<code>_config.deploy.yml</code> and <code>_config.common.yml</code>, where <code>_config.common.yml</code>
|
||||
contained data shared between both the deployed and the locally developed
|
||||
version and the other two just contain a variable that either points to a local
|
||||
folder or my "CDN". However, I have not found a way to do this. Looking back, I perhaps
|
||||
would have been able to just specify the common config first and then specify another
|
||||
config file to acomplish this, but now I am in love with another piece of software.</p>
|
||||
<p>Additionally, I would have liked to integrate the entire webpage building process
|
||||
more with my favourite build system, <em>GNU Make</em>. But <em>Jekyll</em> feels like it attempts
|
||||
to do everything by itself. And this may be true: <em>Jekyll</em> tries to do as much as
|
||||
possible to cater to as many people as possible. As such, <em>Jekyll</em> is pretty powerful, until
|
||||
you want to change things.</p>
|
||||
<h2 id="introducing-makesite">Introducing makesite</h2>
|
||||
<p>While casually browsing the Internet, I came across a small
|
||||
<a href="https://github.com/sunainapai/makesite"><em>Github</em> repository</a> for a
|
||||
static page generator. But this one was different. The entire repository was just
|
||||
a Python script and some files to demonstrate how it works. The script itself was just
|
||||
232 lines of code. The Readme stated that it did one thing and that the author was not
|
||||
going to just add features. If someone wanted a new feature, he or she was free to just
|
||||
add it by themself. Why am I telling you all this? Because this is the - in my opinion -
|
||||
best static site generator I have ever used.</p>
|
||||
<h3 id="simplicity">Simplicity</h3>
|
||||
<p><em>makesite</em> is very simple. In its upstream version, it just generates user defined pages,
|
||||
renders a blog from Markdown to HTML and generates a RSS feed. It does templating, but without
|
||||
using heavy and fancy frameworks like <em>Jinja2</em>. The "<em>Getting Started</em>" section of <em>makesite</em> is
|
||||
shorter than the ones of other static site generators, like <em>Jekyll</em> and <em>Hugo</em>.</p>
|
||||
<p>This may seem like a bad thing. If it does not do thing X, then I cannot use it. But that is where
|
||||
<em>makesite</em>'s beauty comes in. You can just add it. The code is very short, well documented and
|
||||
extensible. It follows the <a href="https://suckless.org/philosophy/">"<em>suckless philosophy</em>"</a>. In my case,
|
||||
I added support for loading different variables based on the file <em>makesite</em> is currently compiling,
|
||||
copying and merging different asset folders - and ignoring certain files - and specifying variables
|
||||
on the command line. Would I upstream those changes? Probably not as they are pretty much unique to
|
||||
my own needs and my own usecase. And that is why <em>makesite</em> is so nice: Because it is not <em>a</em> static
|
||||
site generator, it is <strong>your</strong> static site generator.</p>
|
||||
<h3 id="speed">Speed</h3>
|
||||
<p><em>makesite</em> is fast... Really fast. In the time my Makefile has compiled my page and tar-balled it,
|
||||
ready for deployment, <em>Jekyll</em> is still building it. And that makes sense, <em>Jekyll</em> is pretty powerful
|
||||
and does a lot. But for me, I do not need all this power. This blog is not so difficult to generate,
|
||||
my invite page is not difficult to generate, so why would I need all this power?</p>
|
||||
<pre style="background-color:#2b303b;color:#c0c5ce;"><code><span># Jekyll version
|
||||
</span><span>> time make build
|
||||
</span><span># [...]
|
||||
</span><span>make build 1.45s user 0.32s system 96% cpu 1.835 total
|
||||
</span><span>
|
||||
</span><span># makesite version
|
||||
</span><span>> time make build
|
||||
</span><span># [...]
|
||||
</span><span>make build 0.35s user 0.06s system 100% cpu 0.406 total
|
||||
</span></code></pre>
|
||||
<h3 id="buildsystem-integration">Buildsystem Integration</h3>
|
||||
<p>In case of <em>Jekyll</em>, <em>Jekyll</em> pretty much <em>is</em> your buildsystem. This is not so great, if you already
|
||||
have a favourite buildsystem that you would prefer to use, since it does not integrate well. <em>makesite</em>, on
|
||||
the other hand, does just the bare minimum and thus gives the buildsystem much more to work with. In my case,
|
||||
<em>makesite</em> just builds my blog or my other pages. If I want to preview them, then my Makefile just starts a
|
||||
local webserver with <code>python -m http.server 8080</code>. If I want to deploy, then my Makefile tar-balls the resulting
|
||||
directory.</p>
|
||||
<pre data-lang="makefile" style="background-color:#2b303b;color:#c0c5ce;" class="language-makefile "><code class="language-makefile" data-lang="makefile"><span style="color:#65737e;"># [...]
|
||||
</span><span>
|
||||
</span><span style="color:#8fa1b3;">serve</span><span>: </span><span style="color:#b48ead;">${</span><span style="color:#bf616a;">OPTIMIZED_IMAGES</span><span style="color:#b48ead;">}
|
||||
</span><span> </span><span style="color:#bf616a;">python</span><span> ../shared-assets/makesite.py \
|
||||
</span><span style="color:#bf616a;"> -p</span><span> params.json \
|
||||
</span><span style="color:#bf616a;"> -v</span><span> page_assets=/assets \
|
||||
</span><span style="color:#bf616a;"> -v</span><span> build_time="</span><span style="color:#b48ead;">${</span><span style="color:#bf616a;">BUILD_DATE</span><span style="color:#b48ead;">}</span><span>" \
|
||||
</span><span style="color:#bf616a;"> --assets</span><span> ../shared-assets/assets \
|
||||
</span><span style="color:#bf616a;"> --assets</span><span> ./assets \
|
||||
</span><span style="color:#bf616a;"> --copy-assets </span><span>\
|
||||
</span><span style="color:#bf616a;"> --ignore</span><span> ../shared-assets/assets/img \
|
||||
</span><span style="color:#bf616a;"> --ignore</span><span> assets/img/raw \
|
||||
</span><span style="color:#bf616a;"> --include</span><span> robots.txt \
|
||||
</span><span style="color:#bf616a;"> --blog </span><span>\
|
||||
</span><span style="color:#bf616a;"> --rss
|
||||
</span><span> </span><span style="color:#96b5b4;">cd</span><span> _site/ && </span><span style="color:#bf616a;">python -m</span><span> http.server 8080
|
||||
</span><span>
|
||||
</span><span style="color:#8fa1b3;">build</span><span>: </span><span style="color:#b48ead;">${</span><span style="color:#bf616a;">OPTIMIZED_IMAGES</span><span style="color:#b48ead;">}
|
||||
</span><span> </span><span style="color:#bf616a;">python</span><span> ../shared-assets/makesite.py \
|
||||
</span><span style="color:#bf616a;"> -p</span><span> params.json \
|
||||
</span><span style="color:#bf616a;"> -v</span><span> page_assets=https://cdn.polynom.me \
|
||||
</span><span style="color:#bf616a;"> -v</span><span> build_time="</span><span style="color:#b48ead;">${</span><span style="color:#bf616a;">BUILD_DATE</span><span style="color:#b48ead;">}</span><span>" \
|
||||
</span><span style="color:#bf616a;"> --assets</span><span> ./assets \
|
||||
</span><span style="color:#bf616a;"> --copy-assets </span><span>\
|
||||
</span><span style="color:#bf616a;"> --ignore</span><span> assets/img/raw \
|
||||
</span><span style="color:#bf616a;"> --include</span><span> robots.txt \
|
||||
</span><span style="color:#bf616a;"> --blog </span><span>\
|
||||
</span><span style="color:#bf616a;"> --rss
|
||||
</span><span> </span><span style="color:#bf616a;">tar -czf</span><span> blog.tar.gz _site
|
||||
</span></code></pre>
|
||||
<p>This is an excerpt from the Makefile of this blog. It may seem verbose when <em>Jekyll</em> does all this
|
||||
for you, but it gives me quite a lot of power. For example:</p>
|
||||
<ul>
|
||||
<li><code>-v page_assets=...</code> (only in my version) gives me the ability to either use local assets or my "CDN" for deploying;</li>
|
||||
<li><code>--copy-assets --assets ./assets</code> (only in my version) allows me to copy my static assets over, so that everything is ready for deployment. If I want to use all assets, including the shared ones, then I just add another <code>--assets ../shared-assets/assets</code> and change the <code>page_assets</code> variable;</li>
|
||||
<li>conditionally decide if I want a blog and/or an RSS feed with <code>--blog</code> and <code>--rss</code></li>
|
||||
<li><code>-v</code> allows me to pass variables directly from the commandline so that I can inject build-time data, like e.g. the build date</li>
|
||||
</ul>
|
||||
<p>If I wanted to, I could now also add a minifier on the build target or page signing with <a href="https://github.com/tasn/webext-signed-pages">Signed Pages</a>.
|
||||
It would be more difficult with <em>Jekyll</em>, while it is just adding a command to my Makefile.</p>
|
||||
<p>Another great thing here is the usage of <code>${OPTIMIZED_IMAGES}</code>: In my blog I sometimes use images. Those images have to be loaded and, especially if
|
||||
they are large, take some time until you can fully see them. I could implement something using JavaScript and make the browser load the images
|
||||
lazily, but this comes with three drawbacks:</p>
|
||||
<ol>
|
||||
<li>It requires JavaScript for loading an image, which is a task that the browser is already good at;</li>
|
||||
<li>Implementing it with JavaScript may lead to content moving around as the images are loaded in, which results in a terrible user experience;</li>
|
||||
<li>Some people may block JavaScript for security and privacy, which would break the site if I were to, for example, write a post that is filled with images for explanations.</li>
|
||||
</ol>
|
||||
<p>The target <code>${OPTIMIZED_IMAGES}</code> in my Makefile automatically converts my raw images into progressive JPEGs, if new images are added. However, this
|
||||
rebuild does not happen every time. It only happens when images are changed or added. Progressive JPEGs are a kind of JPEG where the data can be
|
||||
continously loaded in from the server, first showing the user a low quality version which progressively gets higher quality. With <em>Jekyll</em> I probably
|
||||
would have had to install a plugin that I can only use with <em>Jekyll</em>, while now I can use <em>imagemagick</em>, which I have already installed for other
|
||||
use cases.</p>
|
||||
<h2 id="conclusion">Conclusion</h2>
|
||||
<p>Is <em>makesite</em> easy? It depends. If you want to generate a website with blog
|
||||
that fits exactly the way upstream wrote the script, yes. If you want to do
|
||||
something different, it becomes more difficult as you then have to patch
|
||||
<em>makesite</em> yourself.</p>
|
||||
<p>Per default, <em>makesite</em> is more limited than other static site generators out
|
||||
there, but that is, in my opinion, where <em>makesite</em>'s versatility and
|
||||
customizability comes from. From now on, I will only use <em>makesite</em> for my
|
||||
static pages.</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>
|
Loading…
Reference in New Issue
Block a user