git.alexw.nyc home about git garden
    1
    2
    3
    4
    5
    6
    7
    8
    9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28
   29
   30
   31
   32
   33
   34
   35
   36
   37
   38
   39
   40
   41
   42
   43
   44
   45
   46
   47
   48
   49
   50
   51
   52
   53
   54
   55
   56
   57
   58
   59
   60
   61
   62
   63
   64
   65
   66
   67
   68
   69
   70
   71
   72
   73
   74
   75
   76
   77
   78
   79
   80
   81
   82
   83
   84
   85
   86
   87
   88
   89
   90
   91
   92
   93
   94
   95
   96
   97
   98
   99
  100
  101
  102
  103
  104
  105
  106
  107
  108
  109
  110
  111
  112
  113
  114
  115
  116
  117
  118
  119
  120
  121
  122
  123
  124
  125
  126
  127
  128
  129
  130
  131
  132
  133
  134
  135
  136
  137
  138
  139
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width">
    <link rel="stylesheet" type="text/css" href="../style.css">
    <link rel="icon" type="image/png" href="../icon.png">
    <title>alexw.nyc</title>
  </head>
<body>
  <header>
    <table><tr><td><a href="../index.html"><img src="../icon.png" width=20 /></a></td>
			<td>alexw.nyc</td>
			<td><a href="../index.html">home</a></td>
			<td><a href="../about.html">about</a></td>
			<td><a href="//git.alexw.nyc">git</a></td>
			<td><a href="../garden.html">garden</a></td>
		</tr></table>
  </header>
<main>
<h1>Alex's Guide to running a home server (WIP, DRAFT)</h1>
<p>This is a living guide to hosting digital infrastructure. I'm writing this out
of a dissatisfaction with a lot of existing approaches to running a home server. It
seems to me that a lot of self-hosting guides mirror the approaches and
infrastructure of big tech.</p>
<p>This is a living document, and I will update it as I learn more. If you have
suggestions or corrections, please contact me.</p>
<h2>Principles</h2>
<h3>Keep it simple</h3>
<p>Your system should be as simple as possible. Use lightweight tools: this often
means that you will be using things that are not mainstream, as mainstream
tools are often designed primarily with large, modern, distributed,
high-traffic services in mind: not what we are doing here. You may find
yourself using Linux tools that are quite old, from an era were simpler and
more straightforward infrastructure was more common.</p>
<h3>No cloud services</h3>
<p>Some self-hosting guides will say, set up your home server then use a cloud
proxy server, or put things behind Cloudflare. In my view, this defeats the
purpose: if you want true digital self-sufficiency, you should control as much
of your infrastructure as possible.</p>
<h3>Accept limitations</h3>
<p>There are things that you won't be able to do on self-hosted infrastructure.
Rather than compromise another principle to attempt them, accept and work
within these limitations. For example: you will probably not achieve 100%
uptime with your service. Accept this and communicate it to your site visitors</p>
<h2>Operating System</h2>
<p>I choose <strong>Linux</strong> as my operating system. Alternatives to consider, in order of
feasibility, are OpenBSD and Plan9. This guide is focused on Linux because it
is the operating system I am most familiar with, and it is so ubiquitous that
it is easy to find resources, software and guides for configuring Linux.</p>
<p>In terms of distros, I choose <strong>Alpine Linux</strong>. Alpine Linux is a very minimal
distro. I am both familiar with it and philosophically aligned with it. Alpine
Linux uses musl rather than glibc, which may cause software incompatibilities,
but this is less of a concern for the kind of thing you'll be hosting in the
cloud. Unlike something like Raspberry Pi OS, there won't be a step by step
"how-to" guide for running Alpine on the Raspberry Pi. You'll need to develop a
bit of understanding about your operating system. You are welcome to use
another Linux distro if you'd prefer.</p>
<h2>TLDs</h2>
<p>Unfortunately, a lot of TLDs are operated by <a href="https://en.wikipedia.org/wiki/Identity_Digital">Identity
Digital</a> or a similar
for-profit company. These companies are rent-seekers: they seek to profit on
the natural abundance of digital infrastructure by creating walled gardens to
exploit. Companies like this exist all throughout the infrastructure of the
internet, and it is difficult to avoid them, but it is something to consider
when choosing a TLD. Preferring TLDs operated as nonprofits (e.g. .org) or at
least as public-private partnerships is a good idea.</p>
<p>I chose .nyc as my TLD, which is a public-private partnership between the City
of NY and Verisign.</p>
<p>TODO -- update this section. This may be misinformation or incomplete</p>
<p>Some TLDs may have difficulty sending email.</p>
<h2>ISP</h2>
<p>Your ISP may or may not "officially" let you self-host a web server or other
traffic on your network. Whether this is actually enforced depends on your
location and ISP. Do whatever research you can on your ISP, and consider a
local ISP if available.</p>
<p>A better connection is preferable, but you can still self-host with relatively
low upload speeds so long as you lean harder into the third principle (accept
limitations).</p>
<p>Your ISP may or may not have a static IP adress, in which case you may need to
set up DDNS to handle DNS records.</p>
<h2>Hardware</h2>
<p>In terms of hardware, you should be fine with any hardware that can run Linux.
Personally, I use a Raspberry Pi 3B, because I already have one lying around.
This setup is so light that you can probably get away with something as
lightweight as the Raspberry Pi Zero. </p>
<h3>Comments on the Raspberry Pi</h3>
<p>Installing Alpine Linux on the Raspberry Pi is a bit of a challenge, by which I
mean, you will not find any guide that will tell you exactly everything you
need to do. Instead, you should develop an understanding of your specific needs
and how different installation methods may or may not meet them. </p>
<p>Raspberry Pis boot from an SD card, and SD card wear is a problem: SD cards an
unreliable storage medium, and may fail for any reason. I have not found
reliable information about SD card wear and how to avoid it, so I tried the SD
card as inherently unstable and make sure to have regular backups.</p>
<p>For my Alpine installation on the Rasbperry Pi, I uase a combination of this</p> <a href="https://wiki.alpinelinux.org/wiki/Raspberry_Pi">wiki</a> guide, using diskless install, plus a few bind-mounted filesystems, as described in <a href="https://thiagowfx.github.io/2022/01/alpine-linux-on-raspberry-pi-diskless-mode-with-persistent-storage/">this guide</a>.
<h2>Router</h2>
<p>I use <em>OpenWRT</em> as my router software. I much prefer this to using proprietary,
commercial software, whose security I cannot vouch for.</p>
<p>OpenWRT does not auto-update. You'll need to keep on top of security updates
and patch your router regularly. </p>
<h3>Configuration</h3>
<p>I put my publicly-facing infrastructure on a separate VLAN so it should not be
able to access anything else if it is compromised. A combination of these two guides, plus reading and understanding OpenWRT docs, should get you a VLAN set up: <a href="https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_dmz">cli guide</a> <a href="https://forum.openwrt.org/t/guide-to-set-up-dmz-via-luci/21616">web iface guide</a></p>
<h2>Security</h2>
<p>Opening up your network to the public internet means that you'll have to take
security seriously. A misconfiguration can mean compromising your server, and
potentially anything else on your network that the server may have access to.</p>
<p>I do not have any IOT devices, such as a "smart" TV, thermostat, etc. The only
devices on my network are my home laptop, work laptop, and cell phone. I
recommend this as a general principle, not just if you're operating a home server.</p>
<p>Move carefully and make sure you understand things thoroughly before you make
your server accessible to the public</p>
<h2>Software</h2>
<p>Learn Linux a bit. Be able to navigate around your filesystem and understand
how things are laid out. </p>
<h3>Firewall</h3>
<p>I use ufw as my firewall, and block all in and out ports by default. I then allowlist the needed ports. A good place to start is: DNS, NTP, HTTP, HTTPS</p>
<h3>Web Server</h3>
<p>I use lihgttpd as my </p>
<h3>Monitoring</h3>
<p>I use rrdtool for monitoring, which is an older and much lighter-weight alternative to something like Prometheus</p>
<h2>Other helpful resources</h2>
<ul>
  <li>
  <a href="https://www.ooooo.be/atraversalnetworkoffeministservers/">A Traversal Network of Feminist Servers</a>
  </li>
  <li><a href="https://www.youtube.com/watch?v=fx3XcKy7LJY&t=1200s">Counter Cloud Strategies</a></li>
  <li><a href="https://areyoubeingserved.constantvzw.org/Summit_afterlife.xhtml">Feminist Server Manifesto</a></li>
  <li><a href="https://www.paritybit.ca/garden/server-security">Server Security</a></li>
</ul>
<p>For anyone interested in setting up their own home infrastructure, I am happy to help, please send me an email at <a href="mailto:alex@alexwennerberg.com">alex@alexwennerberg.com</a></p>
</main>
<footer>
<a href="/tech/infra.html">live</a> from beautiful brooklyn, new york
<a href="mailto:alex@alexwennerberg.com">email</a>
<a href="https://merveilles.town/@aw">mastodon</a>
</footer>
</body>
</html>