After some time, I noticed that I really like a specific kind of clever domain name, one where the TLD is woven into the site’s own name. I remember exactly where the trick first clicked: Aral Balkan’s ar.al. From there, I started seeing them everywhere: personalsit.es for “personal sites”, jessi.ca for “jessica”, selfh.st for “selfhost” (whose owner took it up a notch and used the dot, too, as a substitute for “o”)… you get the idea. Naturally, I started obsessing over the ilye.ss domain name. ilye plus .ss is “ilyess”. The TLD didn’t hang off the word; it was the last two letters of it. That was the whole magic trick.

When I checked the first time, the .ss TLD wasn’t supported by popular registrars. I managed to find one that had it, but the asking price was exorbitant. I wasn’t ready to pay an arm and a leg for what could objectively be described as an aesthetic upgrade, so I gave up the hunt and accepted the less-than-ideal domain I had.

Recently, my obsession resurfaced. Open source and selfhosting are a steady part of my reading, and selfh.st is always in those rounds — a constant reminder of the trick. Check after check, the idea kept coming back. Before I knew it, I was looking at domain names again. I discovered tld-list.com where I was pleasantly surprised to see a registrar I’d never heard of listing my domain of choice at a fair price. It was still expensive by .cc standards, especially compared to what I first paid, but reasonable enough for me to pull the trigger.

This blog now sports the shiny new domain ilye.ss, and all ilyess.cc links redirect to this new one. The mission is complete. I will stop looking at domain names — at least for this blog.

I spent years coveting a six-letter domain, for a blog about not very much. We all have a vanity project we didn’t really need. What’s yours, the ilye.ss of your projects? Drop it in the comments, reply on Mastodon, or reach out via email. Thank you so much for tuning in. Until next time, take care!

If you’re here, you might be thinking about doing the same. Maybe you’ve heard about self-hosting but feel overwhelmed by where to start. Maybe you think it requires a server closet full of equipment and a networking degree. It doesn’t.

This post covers the services I recommend starting with if you care about privacy and want to own your data. None of these are required. Pick what sounds useful and ignore the rest.

Pi-hole

#

If you only self-host one thing, make it Pi-hole. It runs a DNS server on your network that blocks ads and trackers at the source. Every device in your home connects through it, so you get ad-blocking everywhere on your phone, your laptop, and your smart TV without installing anything on each device individually. I’ve written about my Pi-hole setup before, so I won’t rehash the details here. But the tl;dr is: it works, it’s easy to run on a Raspberry Pi, and the difference in browsing experience is noticeable. Once you have Pi-hole running, you can also use it as your DHCP server, meaning it can hand out IP addresses to your devices, replacing your router’s DHCP function.

Bitwarden

#

We all know we should use a password manager. But most people default to the cloud-hosted version, which means their passwords live on someone else’s server. Bitwarden is an open-source password manager with a Docker image you can run at home. I host my own instance, and it’s been rock-solid. The browser extensions work well, mobile apps are decent, and you get all the features you’d want: 2FA integration, secure notes, password sharing with family. The self-hosted version is free, which is refreshing in a world where everything wants a subscription.

The trade-off with self-hosting is backups. If your server dies and you haven’t backed up your vault, you’re locked out of everything. I solve this by encrypting my vault locally and syncing it to a few public cloud providers, on a regular basis. The data is encrypted before it leaves my machine, so the providers never see my actual passwords — but I get the peace of mind that comes with high availability and knowing there’s always a safe copy somewhere.

Obsidian with Git

#

My note-taking setup has evolved a lot over the years. I’ve tried Evernote, Standard Notes, Joplin, and finally landed on Obsidian with Git sync. Obsidian is a markdown-based note-taking app that stores your notes locally as plain text files. It runs locally on your machine, so it’s not a self-hosted service itself. The magic is in how you sync it. I use Git for that. Specifically, I have a private Gitea instance running on a home server, and my Obsidian vault lives there. Every change gets pushed to Gitea, giving me version history, automatic backups, and complete ownership of my notes. Since everything is just markdown, my notes aren’t trapped in a proprietary format. I own them completely. No subscription, no cloud dependency, no vendor lock-in. If you’re already running Gitea (or any Git server), adding your Obsidian vault to it takes minutes. Even if you’re not, it’s a great reason to set one up.

Jellyfin

#

For media, Jellyfin is a free, open-source media server. Think of it as your own personal Netflix. Rip your DVDs, dump them on a server, and stream to any device in your house. It’s not as polished as Plex — which has moved toward paid features — but it works well and respects your privacy. No accounts, no data collection, no subscription. I run Jellyfin on a modest server and stream to my TV. It’s perfect for having a centralized media library without relying on streaming services.

AudiobookShelf

#

If you listen to audiobooks, AudiobookShelf is a self-hosted audiobooks server, similar to Jellyfin but for books. You upload your audiobooks, organize them by series or author, and stream to your phone or other devices.

You don’t need much to get started. A Raspberry Pi is perfect for beginners. Even a Pi 4 with 4GB RAM can handle Pi-hole, Bitwarden, and a few other services without breaking a sweat. An old laptop or desktop works too if you have one lying around. For networking, a static IP helps, but it’s not required. Dynamic DNS services like DuckDNS work fine if your ISP doesn’t give you a static address.

How long it takes depends on your technical background. If you’re comfortable with the command line and have fiddled with Docker before, you might get up and running in an afternoon. If everything is new to you, expect to spend some time reading and troubleshooting. Either way, the first service is always the hardest. After that, adding more becomes much easier.

Wrap up

#

Self-hosting is a journey, not a destination. You don’t need to set up everything at once. Pick one service that solves a problem you actually have. Maybe it’s ad-blocking with Pi-hole. Maybe it’s finally switching to a password manager. Maybe it’s getting your notes out of a proprietary service.

The important part is starting — you’ll learn as you go, and that’s part of the fun.

How about you? What self-hosted services do you run, or are you planning to set up? I’d love to hear what’s in your stack. Feel free to leave a comment with your setup, or any recommendations you think might improve mine. You can also share your thoughts on Mastodon or reply via email. Thank you for tuning in. Until next time, take care!

Pi-hole DNS in the Host Machine

#

Let’s start with the host machine itself. For it to use the Pi-hole container as a DNS resolver, the loopback² IP address must be set as the DNS nameserver in the host’s configuration. This is usually done by adding the following line to /etc/resolv.conf:

nameserver 127.0.0.1

The Pi-hole Docker container publishes UDP port 53 on the host machine to handle DNS for the entire network. Using the loopback address here tells the host to resolve DNS to “itself”, which routes queries through that published port.

Pi-hole DNS in Neighboring Docker Containers

#

By default, Docker uses the DNS servers configured on the host inside containers unless those servers are invalid, in which case it falls back to Google’s 8.8.8.8 resolver or to whatever resolver is set in Docker’s daemon configuration (typically in /etc/docker/daemon.json). If you use the loopback IP address on the host, as shown in the previous section, Docker treats it as invalid because it would point to the container’s own loopback address, which is not the intended effect. In other words, it would be telling every Docker container to use itself as the DNS resolver — a setup that simply doesn’t work. So, how can we use the Pi-hole container to serve DNS for both the host machine and any neighboring Docker containers?

An option is to use the host’s LAN³ IP address (e.g., 10.10.0.10) instead of the loopback address. In my experience, this approach also failed. When I tested it, I could see DNS queries arriving at the Pi-hole container from neighboring containers, but those requests never completed the round-trip — they timed out from the container’s perspective.

Another alternative is to use Docker networks so that all containers share the network used by Pi-hole. This is the approach I’ll detail below.

Running Pi-hole in Docker, as described in my previous post, automatically creates a Docker network called pihole_backend (assuming the folder that holds the docker-compose.yml file is named pihole). The relevant section looks like this:

1networks:
2  backend:
3    ipam:
4      config:
5        - subnet: 172.31.0.0/16

We want to attach any container that needs to use Pi-hole to this Docker network. To do that, update the service definition in its docker-compose.yml file as follows:

 1service:
 2  myservice:
 3    ...
 4    networks:
 5      - pihole_backend
 6    dns:
 7      - "172.31.0.111" # Pi-hole container's IP address on the pihole_backend Docker network
 8
 9networks:
10  pihole_backend:
11    external: true # Important since this network is created in another docker-compose file (Pi-hole's)

We’re making three main changes:

1. Declare Pi-hole’s Docker network as external so that services defined in the compose file can use it.
2. Attach the service to that network — this lets container communicate with Pi-hole.
3. Configure the service to use Pi-hole’s IP address on that network as its DNS resolver.

After saving these changes, the myservice container will start using Pi-hole for DNS the next time it restarts.

Caveats

#

Unfortunately, these changes have to be added to every container, which makes this approach error-prone. It’s up to you to remember to insert those lines in the docker-compose.yml file before deploying a new service; otherwise the container will fall back to Docker’s default public DNS resolver.

Another drawback is that the Pi-hole stack must be deployed first so the pihole_backend network exists for the other containers to join. That requirement makes sense — containers can’t use Pi-hole for DNS until it’s running — but the dependency isn’t expressed in a way that drives the deployment sequence. Unless all services are defined in the same compose file and are explicitly configured to depend on the Pi-hole service, you have to manually verify that the Pi-hole stack is online before launching any dependent stacks.

If you know of a better approach that avoids these caveats, please let me know!

Wrap Up

#

I explained how to use a Pi-hole Docker container as a DNS resolver on the host machine and discussed some challenges of using it from neighboring Docker containers. I then presented a workaround and highlighted its remaining shortcomings. I hope you found this article informative, or at least enjoyable. I’m always eager to hear from you, so feel free to drop a comment below, fire off a Mastodon reply, or send me an email. Thanks again for tuning in. Until next time, take care!

In this article I’ll briefly outline the tools I’ve been using to manage public discussions on this blog, explore other comment-management solutions, and describe the changes I’m implementing in my current setup moving forward.

How I Manage Comments Today

#

Whenever I publish a new post, I also share it on Mastodon hoping to spark a constructive conversation. In this way, Mastodon serves as a rudimentary comment-management system: It lets me announce a new article and exchange thoughts with people across the Fediverse, all from the comfort of my own Mastodon account. Many fellow bloggers have adopted the same strategy, and that’s perfectly reasonable. The approach is extremely low-effort, requires virtually no maintenance, is completely free, and leverages the Fediverse that those bloggers already belong to.

A major downside of using Mastodon — or any other social-media platform — in this way is that it pulls the conversation away from the blog post being discussed. That disconnect can discourage readers from sharing their thoughts, or cause them to miss the conversation entirely if they skip the paragraph where I usually drop the Mastodon link. As a workaround, some developers have created scripts that automatically fetch Mastodon replies and display them below the article. In my view, while this improves the reader’s experience somewhat, it’s still suboptimal because participants have to leave the blog and hop onto the Fediverse to join the discussion.

Another limitation of using Mastodon as a comment-management tool is that it excludes anyone without a Fediverse account. This shortcoming isn’t unique to Mastodon — most social-media platforms and any comment system that requires an account share the same issue — but it remains a drawback in my view.

Time for a Change

#

It’s time to try something new. I’ve been considering adding a more comprehensive comment-management solution to this blog for a while, but I never fully committed until recently. Adding comments to a static site is a contentious proposition — it forces you to pause and weigh the trade-offs before making a decision.

On one hand, I completely understand the purist view that comments are inherently dynamic while static sites are meant to stay static. Moreover, maintaining native user-registration and login just to enable comments often isn’t worth the effort for most personal blogs. And third-party comment providers usually fall short on privacy, and they rarely blend seamlessly with a site’s design.

On the flip side, comments can prompt dialogue and give the author a place to solicit reader input. They’re also more accessible because readers don’t need to be on the same social-media platform as the author to leave a remark.

I wanted to gauge what the Fediverse community thought about this, so I posted a question about comment management on blogs and received a range of responses. The question was:

If you have a blog, what do you use for comment management?

1. Third party comment provider like Disqus or Github
2. Native comment management
3. Webmentions
4. Other

To my surprise, most of the votes favored native comment management, with “Other” in second place and Webmentions¹ third. Unsurprisingly, “third-party comment providers” ranked last.

Alongside the poll results, I received excellent suggestions and caught a glimpse of the tools others use to solve the same problem. This reinforced the notion that some form of commenting — whether minimal or extensive — is welcomed, if not encouraged, and that leveraging Mastodon or the Fediverse in general remains a popular strategy among bloggers. A few brave contributors even explained how they implement native comment systems and kindly shared valuable resources for further learning. So I dove down the rabbit hole, searching for the perfect native comment solution for my statically generated blog.

New Kid on the Blog

#

In my quest for the perfect native comment-management system, I kept a short list of requirements:

1. Open-source and self-hostable: I don’t want to rely on a third party for comments.
2. Anonymous submissions: Lowering the barrier encourages participation.
3. Easy moderation: Preferably with an option to require admin approval for every submission.

A few projects caught my eye during the search. The first was Isso, an open-source alternative to Disqus with Markdown support. The second was Comentario, which offers a very similar feature set but with a slightly more refined UI and documentation. I chose the latter. Its sleek admin interface and extensive comment-section customizability won me over instantly. Because I don’t want to manage user accounts or logins, I enabled the always-anonymous mode. Visitors can still supply a name for display purposes — a name that doesn’t have to be their real one.

After a while, I set up my Comentario instance and tweaked the UI to match my site’s overall theme. It’s now ready to accept comment submissions. This post will be the first to enable native comments, with plans to roll them out to the rest of the articles if they prove stable enough. I’d really appreciate it if you’d drop a comment below to help me test the system — do it for science!

All other existing feedback and comment channels will stay untouched, so I’ll keep posting my blog entries on Mastodon as well. The goal of adding native comments is to expand the current comment hub, not to replace it entirely. You can still email me or continue engaging on Mastodon if you prefer.

Wrap Up

#

I explained why I’m shifting away from Fediverse-only chatter, outlined the basics I needed in a comment system, and shared how I landed on Comentario. The new comment section is now live, but the old channels (email and Mastodon) remain open.

Give the new comment box a spin, fire off a reply on Mastodon, or shoot me an email. Your feedback keeps the conversation flowing, and I’m excited to hear what you think. Until next time, take care!

The Unexpected EFI Snag

#

I booted into the live Arch Linux ISO, and chrooted¹ into my Arch installation. As I inspected drive partitions to mount them correctly, I noticed that the EFI partition was mounted on /efi. That instantly caught my attention — I remembered from reading the Systemd-boot Arch wiki article that /efi isn’t mentioned as a supported EFI path. By default, bootctl install looks for /boot and /boot/efi. Apparently, Systemd-boot doesn’t support /efi as a mount point for the EFI partition just yet, even though the Arch wiki discourages mounting the EFI partition under /boot/efi. Hopefully this will be addressed in a future version. Separating the boot and EFI partitions comes with plenty of benefits. The main ones are:

• Separation of concerns between the OS and UEFI files;
• Ability to encrypt kernel images in /boot; and
• On-demand EFI partition mounting during boot loader upgrades.

So, I changed the mount location to /boot/efi to see if it made any difference.

Light at the End of the Tunnel

#

Now that the EFI partition was mounted at /boot/efi, I ran the bootctl install command again and lo and behold, no EFI var input/output error! It seemed to work? I followed the Arch wiki to create the loader configuration file alongside an entry file for my Arch installation. A quick reboot brought up the Systemd-boot menu as expected, with my new Arch entry selected as default. Wonderful!

I’m glad I took the time to carefully go over the Arch wiki’s Systemd-boot article. Otherwise, I’m not sure I would’ve guessed that the mount point of the EFI partition had anything to do with the EFI vars error. Also, props to the Arch wiki maintainers — you all are heroes!

There was one small problem. I couldn’t boot into my Arch Linux system through the Systemd-boot menu. Specifically, the boot entry generated by the bootctl command wasn’t able to properly load my Arch installation. My system sits on a LUKS-encrypted³ partition, so I can’t use the default boot entry configuration. Back to the hunt for the right option parameters that would enable Systemd-boot to correctly boot my system.

The exact configuration wasn’t straightforward, to be frank. I had to dig around in old forum posts, go through the man page of bootctl — several times — and try out a bunch of option variations⁴. Eventually, I managed to concoct just the right boot options for Systemd-boot to decrypt the partition and load the system.

There was still one small problem⁵. My system still wasn’t booting, and this time the problem wasn’t with Systemd-boot directly. Kernel and initramfs⁶ image files live under /boot by default, but that’s not where Systemd-boot was looking. It checked /boot/efi since that’s where my EFI partition was mounted. So, I had to manually copy kernel and initramfs image files to /boot/efi because I wasn’t able to directly reference these files from /boot. What I mean is that in the loader entry file, these image files are referenced as follows:

linux	/vmlinuz-linux
initrd	/initramfs-linux.img

The / here references the EFI partition, /boot/efi. Ideally, I should be able to go up to the parent folder and grab the image files like so:

linux	../vmlinuz-linux
initrd	../initramfs-linux.img

Or maybe like:

linux	/../vmlinuz-linux
initrd	/../initramfs-linux.img

Unfortunately, none of those attempts bore any fruit. I had no choice but to copy those files manually from /boot to /boot/efi and see if it fixed the issue. I rebooted the machine, speed-typed the decryption passphrase, hit Enter and stared at the screen in anticipation. As the milliseconds rolled by, a wall of log messages washed over the black screen. With every new line my hopes built up — until I was greeted with “Welcome to Arch Linux!”. I finally made it, people!

Clean Up

#

The system was properly booting the current kernel, but it wouldn’t boot the next kernel version unless I manually copied over its images to /boot/efi. Frankly, I didn’t feel like doing this by hand after every kernel update — if I even remembered to do it at all. So, automating this process was a mandatory next step.

There are different ways of achieving this. I opted for updating the mkinitcpio⁷ Linux preset to target the correct location when building kernel and initramfs image files. It’s a fairly simple configuration update. Once ready, I tested it by rebuilding the current kernel images and ensured they were indeed placed in the expected location.

Now that my boot sequence was properly configured with Systemd-boot for current and future kernel versions, it was time for what I’d been longing for all along:

sudo pacman -Rns grub

I got rid of GRUB and got my system that much closer to its ultimate lean state. Man, did it feel good to kick those few dozen megabytes out of my system. I never thought one could draw so much pleasure from running a single Linux command.

Retrospective

#

You might be thinking “That’s an awful amount of time, effort, and energy put into deleting a single package”. And I’d be the first to agree. Did I have to go through all this torture? Not really; GRUB worked just fine and I never had to touch it since the first time I set it up. Would I do this again now that I know how tumultuous the path to perfection can be? Hell yeah! Yes, it was challenging — but that’s where the fun lies. I learned so much from this little mission. By the time I reached the final stages, I was decrypting my root partition from the live ISO TTY⁸ with the confidence of a seasoned expert and chrooting in to mess around with Systemd-boot configuration files that I knew exactly where to find. Hacker status: Unlocked! Yeah, that felt pretty good.

Yet, even as I gained proficiency in Systemd-boot and manipulating system configuration from a live ISO, a few lingering questions remained unanswered. The first is the EFI vars error. The problem from the dual boot article, which instigated this whole endeavor is unfortunately still here. Trying to update EFI vars still throws that input/output error, even with Systemd-boot. For instance, any attempt to modify the boot order invariably results in this error. As a consequence, my machine still launches the Windows bootloader, where I have to hit Escape to switch to the Systemd-boot loader screen. I still don’t know what the root cause could be, and quite honestly, it bugs me. The one consolation in all this is the confirmation that the bootloader is not to blame. At least, neither GRUB nor Systemd-boot is the culprit.

The second question concerns the EFI System Partition (ESP). Based on my understanding, a single ESP is technically sufficient for UEFI to function, as it serves as the central location for boot files. Consequently, in multi-boot configurations, it’s possible to consolidate all operating systems under a single ESP, using one bootloader to manage them collectively. Is this accurate and feasible? I currently have multiple EFI partitions — one for each OS on my computer.

Wrap Up

#

Recovering from a broken Linux installation proved to be a journey filled with unexpected challenges and valuable lessons — from debugging EFI partition mounting issues and Systemd-boot configurations to customizing the kernel update process and finally bidding farewell to GRUB. Along the way, I learned a lot about the Linux boot process, the benefits of separating boot and EFI partitions, and Systemd-boot in general. While the transition to Systemd-boot was ultimately successful, some questions are still unresolved, as detailed in the previous section. If you have insights or solutions to these puzzles, feel free to reach out on Mastodon or via email.

I appreciate your time and interest and hope these experiences resonate with or assist your own Linux adventures. Until next time, take care!

I slowly built up the reflex of checking out both the desktop and the phone whenever I’m looking for a note. That worked surprisingly well; It didn’t feel like I was missing out on much. There might have been a handful of occasions where I needed a note copied over to the other system, but transferring it manually wasn’t that big of a hassle. The system was stupidly simple, just the way I like it, so I stuck with it for some time.

A Serendipitous Discovery

#

One day, I found out about a new Neovim plugin for Obsidian. It allows you to interact with your Obsidian¹ vault from the comfort of Neovim². This alone was enough of a reason for me to take it for a ride, and let me tell you: I instantly fell in love! I do all my writing in Neovim anyway, including taking notes, so this was right up my alley. The plugin has some nice features like browsing tags, easy note linking, note templates, and more³. This pleasant experience led me to revisit Obsidian as a dedicated note taking solution on both desktop and mobile.

After some digging, I discovered that Obsidian supports data synchronization through a Git server. And the cherry on top is that it doesn’t have to be Github or any specific Git platform; any Git server will do. This was the last piece of the puzzle for a new note taking system.

The New System

#

With these new findings, I spun up a local Gitea⁴ instance to carry out the sync; I installed Obsidian on both my phone and desktop and configured them to connect to my Gitea server. I admit I couldn’t make it work on the first try, but after some fiddling the system was operational. Notes are finally synchronized on both ends through the Gitea server.

The new system consists of 3 components:

1. Neovim on the desktop with the Obsidian plugin
2. The Obsidian app on my phone
3. A local instance of Gitea

Not only is this system superior to its predecessor, it also maintains the same freedom from vendor lock-in and privacy guarantees. It:

• Uses an open file format: All note files are in Markdown; my favorite text format.
• Is completely offline: I’m hosting the Gitea sync server off the internet so it’s only accessible within the local network, for maximum privacy;
• Is private and ad-free: Neither Obsidian nor Gitea has any telemetry or ads.
• Is totally free but partially open source: Both Obsidian and Gitea are free, but only Gitea is open source.

This setup basically checks most of the boxes; I couldn’t be happier. I think I finally cracked the code and put together a system that can last. So much so that I haven’t felt the need to explore other note taking options in a long time now⁵. Unless my current use cases change dramatically, I’m going to call this one “problem solved.” Given my picky nature and perfectionist tendencies, I don’t get to do this that often.

Caveats

#

One limitation of the system is the fact that synchronization only takes place when I’m connected to my local network. This is by design for increased privacy, but it comes with a slight inconvenience. At times, I make changes to a note offline, say on my phone, when I’m away from my local network but forget to trigger a sync when I’m back. If I happen to update the same note on the desktop and sync the changes, it will cause a Git conflict the next time my phone attempts to sync. This doesn’t happen often enough to be annoying, however. It’s just an edge-case that I need to be mindful of. Besides, I’ll take this limitation over having my precious notes out on the internet any day of the week.

Wrap Up

#

It’s been a long journey trying to customize my note taking process. My preference for simplicity and privacy kept me on the hunt for the perfect system. I finally landed on Obsidian, despite having discarded it in the past, with a custom Git server for synchronization. How about you? What’s your note taking process like? Feel free to share your setup, or any recommendations you think might improve mine, on Mastodon. You can also reply to this post via email. Thank you very much for tuning in. Until next time, take care!

“Hey, we collect a bunch of data about your usage of this website and share it with 998723487 of our partners. Tell us you agree by clicking the only button below”.

If you’ve grown annoyed by this practice, you’re not alone. No one asked for this, yet we all have to do this dance whenever we want to visit a website like some sort of ritual jig at the entrance of a religious site. How did we get here? Why did the entire internet all of a sudden get plagued by these Popup windows, and is there a better way to accomplish what they were designed for without all the dark patterns?

How Did We Get Here?

#

In 2016, the European Union (EU) published the General Data Protection Regulation (GDPR) which is a set of rules that govern website practices operating inside the EU. GDPR’s main goal is to protect users’ online privacy. This was a long time coming and I’m glad the EU took this step. The practices some websites adopted have gotten way out of control and turned them into pervasive data mining devices. Without going in too much detail and drowning in lawyer jargon, the GDPR stipulates that websites must inform their users of any data stored on their device (this obviously includes cookies) along with the purpose of doing so, and collect their consent. This sounds like a great idea — it gives the user control over their computer: They get to decide whether any external entity is allowed to store and access data on their machine. Notice that there’s no mention of Popup windows; the implementation was left up to website operators to define and that’s where the mandate fell short in my opinion.

To comply with these regulations, companies introduced a dialog box on their website asking visitors for permission to use cookies. Most of them don’t allow any user action on the website until the cookie Popup window is addressed. Some even deny users access if they don’t accept, so is it really a choice after all? It gets worse. Some websites default to collecting your data and using cookies until you click the “Decline” button. So the choice boils down to:

1. Accept, otherwise you can’t do anything; or
2. Deny, so you can’t do anything; or
3. Ignore, which is effectively the same as “Accept”.

What a mess!

Can We Do Better?

#

GDPR merely talks about providing information around data stored on users’ devices and collecting their consent, without dictating how to do so. A better approach to achieve this, in my opinion, is to have a browser setting to indicate consent. In the absence of this consent indicator, websites must refrain from storing and/or accessing browser cookies, in order to comply with GDPR. The good news is we already have a browser setting that was designed specifically for use cases like this one. It’s called the Global Privacy Control (GPC). It’s a simple HTTP header that signals the user’s opting out of tracking or having their data collected and/or sold.

GPC is a valid do-not-sell-my-personal-information signal according to the California Consumer Privacy Act (CCPA), which stipulates that websites are legally required to respect a signal sent by users who want to opt-out of having their personal data sold. — Wikipedia¹

I don’t know about you but to me, this sounds like exactly what we need for the job. Users could install a browser extension that automatically attaches this HTTP header to all outgoing requests. I haven’t looked but I bet there are multiple extensions meant for this or that could be used for this purpose. Or better yet, browsers could natively support this feature through a setting toggle. Once configured, all visited websites would receive this header and therefore be informed of the user’s opt-out decision. No Popups needed — totally transparent for the end user.

If such a simple solution exists, why did the industry rush to implement cookie consent Popups? Why build a UI element with text, links and buttons, worry about scaling and placement, bloat the page DOM², and potentially increase load time? While I can’t claim to have a definite answer to these questions, I can sure take a guess.

See? With a simple HTTP header that the browser broadcasts online, there’s no wiggle room. The signal is clear: either the header exists with a value of 1 or it doesn’t. It’s binary, and not up for debate. In the case of a Popup, however, websites still have a chance to wheedle the user into opting in to data collection. With a Popup, they’re free to deploy all the dark patterns in the book to get you to act in a certain way: to surrender your consent, in this case. They get to design the Popup so that it covers the entire page for instance, to maximize friction; make the “Accept” button so atrociously flashy that you’re blinded to everything else around it; make it so effortless to click, or tap, that it almost sucks in your cursor, or thumb, like a powerful vacuum cleaner in face of an empty plastic bag. They get to make the “Decline” button so minuscule that it’s destined to be missed.

• Wait! Does it have to be a button? Let’s make that a link… And make the font color merely a couple bits off the background color so it’s only visible under a narrow wave length band of UV light.
• Hold on! Should we even bother with a “Decline” button or link? Yeah, let’s just leave it out.

I recognize that I’m generalizing here. There are probably websites out there that already honor the GPC header, and others that found ways to do without cookies altogether. However, it still feels like the vast majority of websites fall in the cookie Popup camp, unfortunately.

Where Do We Go From Here?

#

In my opinion, all regulations in place today must be revisited to explicitly prohibit these dark patterns and clearly endorse, if not require, the use of GPC for the purpose of tracking consent collection, like the CCPA. In the meantime, I suggest you equip your browser with a good ad/tracking blocking add-on like uBlockOrigin, and configure GPC.

Wrap Up

#

And that’s why I believe cookie Popups were a big mistake. I hope I managed to get my points across and that my lousy humor didn’t put you off too much. Now, I’m curious to know how you deal with the annoying cookie Popups. Do you mindlessly hit “Accept” every time just to get through? Do you use some sort of browser add-on to block or bypass this step? Let me know by replying to this post on Mastodon or reaching out via email. Thank you so much for tuning in. Until next time, take care!

Configuring Systemd-boot

#

Given the sensitive nature of the boot process, I took some time to prepare a bootable USB drive with the Arch Linux ISO⁴, before changing anything. I picked Ventoy⁵ for the job. It’s a nice piece of software that I’ve been wanting to try out anyway.

On the surface, setting up Systemd-boot is fairly simple. All you have to do is run the bootctl install command and that should take care of everything. Unfortunately, that didn’t go so smoothly for me. The command resulted in an EFI vars input/output error - an error I’m starting to get annoyed by familiar with at this point. I ensured that my system was booted through UEFI⁶, and that EFI vars were all loaded as they should. I went through bootctl’s man page and ran the command a bunch of time with different flags, but it kept falling flat. It copied some files into the boot location but always ended in that EFI error. Despite my enthusiasm to get Systemd-boot working, I had to shift gears and focus on my EFI situation before I can make any meaningful progress.

Stubborn EFI

#

I started by resetting the BIOS to its default configuration. That only made matters worse because it enabled Secure Boot which blocked the bootloader, so I had to turn it off⁷. After that, I cleared the NVRAM⁸ state that holds EFI vars. It didn’t seem to make a difference, except that it nuked the GRUB loader. Now, I’m getting a Systemd-boot loader instead with a single entry to reboot into BIOS. I’m not sure if this was the result of wiping the NVRAM or the bootctl install command. Perhaps the command did actually work halfway despite the EFI input/output error? Either way, now that the bootloader is corrupted, there’s no giving up. I must sort this out if I want to get my system back up and running.

Next, I flushed the BIOS with the latest firmware. This part took way more time than I’m willing to admit. I didn’t have a spare USB stick on hand to use for the firmware update. So I needed to find a way to use my Ventoy USB drive without having to remove Ventoy, because I might need it to boot into a live ISO for debugging. By default, Ventoy creates 2 partitions on the USB drive: One bootable partition for Ventoy itself, and another exFAT⁹ partition to host ISO files. I figured I could just drop the firmware file in the exFAT partition and load it from the BIOS. Not so fast there, Stacy! The BIOS native file browser couldn’t find the Ventoy partition for some reason. I kept looking and browsing other disks from the BIOS in search for the firmware file, but to no avail.

Well, it turns out my BIOS doesn’t support exFAT partitions. Or so it appeared - all I know for sure is that I wasn’t able to get to the Ventoy partition from the BIOS. Next step was to format that partition using a more widely supported filesystem, like FAT32. Luckily, that did the trick. I was able to read the now-FAT32-formatted Ventoy partition, find the firmware file, and flush it to BIOS. Once this side quest completed, I could go back to the main task: figuring out the EFI vars IO error and installing Systemd-boot.

Now that the BIOS is running a shiny new firmware version, I can finally get down to business. I grabbed a copy of the Arch Linux ISO and placed it in the Ventoy partition. Fortunately, formatting the Ventoy USB drive only formatted the partition where ISO files are stored and didn’t touch the Ventoy bootable partition, so Ventoy was still intact. On top of that, Ventoy supports FAT32 partitions which means I didn’t have to reformat that ISO storage partition. I’m telling you, Ventoy is a piece of art!

I’m now at a point where I can simply boot into the Arch Linux ISO, chroot into my system, and install Systemd-boot. If you’re thinking “yeah, right. Easier said than done.” you’d be totally right. But this article is getting long already, so I’m going to have to cut it here. Stay tuned for what happens next.

Wrap Up

#

You saw how I managed to totally obliterate my boot loader thereby rendering the whole system unbootable. I’ve gone through the steps I took to troubleshoot the problem, and touched on some findings like the lack of exFAT support in my BIOS for firmware updates, and the discovery of the amazing bootable USB drive tool called Ventoy. How about you? When was the last time you broke your Linux system and what was the issue? Also, if you have any ideas on what could be wrong with my EFI vars, I’m all ears! Feel free to reach out on Mastodon or via email. Until next time, take care.

My Dual Boot Setup

#

I currently have a dual-boot setup with Windows and Arch Linux on my computer. Wait! Before you leave, let me explain. I don’t use Windows, and haven’t in many years now. When I first got my computer back in the day, it came with Windows installed. So when it was time for me to completely switch to Linux, I just created a second partition to host my new favorite OS and left the Windows partition there until I get around to backing up any data I might have left behind. Needless to say I never got to do that. This hasn’t really bothered me, to be honest, since the Windows partition is small and I have way more disk space than I need on the Linux partition. When I installed my current Linux distro², I had configured Grub to default to it, so I don’t even see the Windows entry most of the time and I’ve kind of forgotten it was there. To recap, I have Grub as my bootloader that supports both my Arch and Windows installations, and the Windows bootloader is completely out of the picture.

The Investigation

#

Now, back to the power outage. I was confused by the Windows bootloader and didn’t know where to go from there. Hitting the escape key took me to the BIOS menu. Nothing seemed to trigger Grub to load. Since I was on the BIOS menu, I went to check the boot order. That seemed fine, except the item for booting from the hard drive now had “Windows” in the name, instead of “Grub”. I was getting a bit stuck, and slowly coming to terms with the possibility that it might be a hardware failure.

I figured the boot partition got corrupted by the power outage, so I whipped out my trusty Linux flash drive and plugged it in. Once in the live environment, I tried to mount the boot partition and inspect it. Everything looked normal. I was able to mount all partitions and read their content. The problem had to come from somewhere else.

Next, I started poking around a little deeper in the BIOS menu, since I kept being taken there whenever I tried to skip the Windows bootloader. I noticed that Secure Boot was enabled despite having a vague memory of having to disable it in the past. I decided to disable it and see what happens. I rebooted the computer and to my disappointment, the Windows bootloader was drawn on the screen. “I have to keep digging!”, I thought to myself. I hit the escape key, ready to peel off even deeper layers of the BIOS menu, except it didn’t show up! I was instead taken to the Grub loader. Finally! I can boot my Arch installation once again. It seemed as if my computer reset the Secure Boot to “enabled” in the BIOS after the power outage. I have no idea why this would happen, though. Perhaps the motherboard battery was drained so the firmware got reset to its factory settings when the power came back? Unclear.

Now that I have a workaround to load my beloved Linux installation, I started troubleshooting the Grub configuration and EFI boot setup. Grub looked fine. I even reloaded the configuration, which had no noticeable effect. I used the efibootmgr command to examine the EFI boot configuration and noticed that the boot order was off indeed. The Windows Boot Manager was the one set to launch first, which explains the problem I was seeing. But when I tried to update the boot order with efibootmgr -o in order to promote the Grub loader to the top of the list, I kept getting a weird error that read:

Could not set BootOrder: Input/output error
error trace:
 efivarfs.c:441 efivarfs_set_variable(): writing to fd 5 failed: Input/output error
 lib.c:78 _efi_set_variable_mode(): ops->set_variable() failed: Input/output error

I did some research to understand what this was all about but without any conclusive findings. So, I decided to call it a win and not invest any more time on this issue, especially since I at least have a reasonable workaround. It’s just an extra keystroke³ during boot time. Furthermore, I have been planning to nuke the Windows partition for the longest time but haven’t had the chance to get to it. Maybe this is yet another reason to bump that up in my to-do list.

Wrap Up

#

Given where this problem started, i.e. not being able to boot my Arch installation at all, I’m glad I landed in a position where I can at least get to the Grub menu during boot time. However, I’ve got to admit that I’m still very curious about the root cause of the immutable EFI boot order. Have you had a similar issue before, or know what could be causing this? If so, please reach out on Mastodon or via email. I would love to hear your insights! If not, no big deal. Thanks for tuning in to my latest struggle in my Linux journey. Until next time, take care!

Fast-forward to today, or more accurately few days ago, and I finally managed to get my NVIDIA card working on Arch Linux and Wayland with no hacky workarounds or precarious maintenance routines. It just works! It worked right after I sorted everything out, it works after reboots, it’s working right now as I type these words on my terminal that renders through the dedicated graphics card (yes, you can have your terminal run on the GPU - maybe it’s a topic for another post), and should continue working after driver updates that are managed by my package manager! Can you believe it? All right, I’m getting ahead of myself here - I got to tame my excitement, and tell you how I got here.

The Struggle

#

I’ve been using open-source graphic drivers that support NVIDIA, like Nouveau, for the bigger part of my time on Linux. The problem was… they all suck, if they work at all. As a matter of fact, I was inadvertently using the integrated GPU with the dedicated one completely off for so long without noticing. That’s how comparable NVIDIA’s performance with open-source drivers was to that of just plain simple integrated GPU. Watching my NVIDIA card sit there and collect dust never sat well with me however. At first, whenever I had some free time I would take another stab at making it work. I had some noticeable success when I was on X11 by using the official proprietary driver straight from NVIDIA’s website. It worked well with few caveats that I was ready to put up with for the sake of an improved graphic experience.

Sadly, when I switched to Wayland, all hell broke loose. Those two (NVIDIA and Wayland) did not like one another - they actively despised and energetically repelled each other. It was like trying to sit a magnet on top of another with similar poles facing each other. I remember once diving so deep in the rabbit hole that I found the line in Gnome’s source code where they explicitly ignore everything that has to do with NVIDIA when Wayland is loaded. Yeah, it was that bad! Shortly after this attempt, with a vivid memory of so many failures, black screens, frozen desktop environments, bricked systems, and geometrically paradoxical screen resolutions, I silently gave up. I felt like my hands were tied and that there wasn’t much I could do to marry NVIDIA and Wayland on my machine. This isn’t to say that it was impossible. I’d read multiple testimonials of people enjoying the full performance of their NVIDIA cards with Wayland, but there was something with my system that made reproducing a similar configuration challenging, to say the least. But, this all changed few days ago.

The Win

#

A short while ago, I randomly decided it was time I tried to sort out my NVIDIA+Wayland situation. I don’t remember exactly what triggered it. The trauma from previous attempts had started to fade away, I suppose, and I had some time on my hands so I thought “Why not?”. I headed over to the trusty Arch Wiki, read through the NVIDIA section, and diligently followed the steps that applied to my system and configuration. Surprisingly, all I ended up doing was installing the official NVIDIA driver from the official Arch package repository (this wasn’t available last time I tried by the way, so it gave me hope on the spot), and updating the /etc/mkinitcpio.conf file to remove kms from the HOOKS array. Et voila! I rebooted my system and there it was - the NVIDIA card was working! I could see it in the nvidia-smi output, and I could feel it in the smoothness of the animations and the responsiveness of the system. I was ecstatic! I couldn’t believe it was that easy. I was so used to the idea that getting NVIDIA to work on Wayland was a monumental task that I had to prepare myself for, that I didn’t even consider the possibility that it could be as simple as installing a package and updating a configuration file. I was over the moon! But, I wasn’t done yet.

Now that I had the NVIDIA card properly configured, I wanted to make the most out of it. But I didn’t want to use it all the time. I wanted to keep the hybrid setup I had going on with the integrated GPU handling the day-to-day tasks and the NVIDIA card kicking in for the heavy lifting when strenuous rendering was needed. The default hybrid mode was doing a pretty good job at this, but I wanted to take it a step further. I wanted to force the NVIDIA card to render specific apps that I knew would benefit from the extra power, like Firefox when watching videos. I spent quite a bit of time on this and I’m happy to say that I managed to get it working. I used the prime-run command to launch the apps I wanted to render with the NVIDIA card, and it worked like a charm. I was hoping to accomplish this without manually updating the launch command of each app, but I couldn’t find a way to do it. If you know of a different way to achieve this, please let me know via email or on Mastodon.

What’s Next

#

I’m not done yet, unfortunately. Nothing needs a powerful GPU more than games, and I haven’t had the chance to test any games yet. I can finally satiate my envy of Linux gamers and see what all the fuss is about. I’m excited to see how games run on my system. I’m not expecting to be blown away by the performance, but I’m hoping to have a decent experience.

Also, I still want to move back to a window manager. I’ve been using Gnome for a while now because I really wanted to switch to Wayland, even if it meant forfeiting my beloved window manager. But now that I have successfully configured NVIDIA to function seamlessly on Wayland, I’m finally able to return to the refined simplicity of a window manager. I have my eyes set on Sway. Having heard numerous commendations, I’m eager to explore its merits and experience it firsthand. I’ll probably publish a post on the subject once I’ve had some time to play around with Sway. So, stay tuned¹ for that.

Wrap Up

#

My goal with this post was to give you a glimpse into my journey with NVIDIA on Wayland. I wanted to share my struggles, my wins, and my plans for the future. I hope you found it interesting and maybe even helpful. If you’re in a similar situation, I hope this post gives you hope that you can get NVIDIA working on Wayland too. If you have any suggestions, tips, or questions, please don’t hesitate to reach out on Mastodon or via email. I’d love to hear from you. Until next time, take care and Happy New Year!

Usernames and Phone Number Privacy

#

Signal finally launched usernames this week. This feature has been in the works for so long, I bet most people have already given up on it. So much so that an inside joke was born out of it; it’s called “Real Soon Now”. I believe this started about 2 years ago when the former CEO Moxie had publicly posted those words in response to a tweet asking about the launch date for usernames. You know, those “usernames when” type of tweets. Anyway, now that the feature is out, let’s take a look at what the hype is all about and see how people have reacted to the news so far.

What Signal calls a username is a nickname at least 3 characters long and a number discriminator of at least 2 digits, joined with a period (e.g.: bob.17). The username is attached to a Signal account and is meant to replace the phone number for contact discovery. In other words, with this feature you’ll no longer have to disclose your phone number in order to start conversations with others on Signal. Alongside usernames, Signal also launched what they call Phone Number Privacy (PNP) which basically allows you to hide your phone number from everyone on Signal, including people you’re already talking to (your so called “Signal connections”). Furthermore, PNP allows you to prevent your account from being discoverable by your phone number. This addresses a lot of concerns around anyone being able to probe Signal servers and discover whether a particular phone number is registered.

This is great! We now have a way to send someone a short chain of characters, a link, or a QR code, to start a chat on Signal without ever revealing our phone number. But there’s something slightly different about Signal’s implementation of usernames that hasn’t caught on (not yet at least) despite their detailed explanation.

The Land Grab

#

Unlike other popular messaging and social media services, Signal manages usernames quite differently. In fact, I think they should’ve used another name for it altogether. Here’s why. While a username in the social media world refers to a handle that represents the account, and acts as its sole identifier in every aspect of its interaction with the service, a username in Signal is merely a reference point to establish first contact. In other words, as soon as you start a conversation with someone who you found through their username, and they accept it, their username becomes entirely irrelevant. All you see is their profile name, photo, bio, etc., the same way you did before the username launch. In addition, usernames can be, and are actually designed to be, readily changeable, if not ephemeral¹. The intent is to give a means of discovery other than, in fact in lieu of, the traditional phone number, and that’s it. Now the intent is one thing, but what actually happens is a whole other story.

As soon as the Signal usernames launch hit the news, the land grab began. Everything we just said about throwaway usernames, only needed for the initial link and all? Take that and throw it out the window. It seems like very few people actually got it, or cared. For the vast majority, a username is a username is a username. It’s my handle, my identity, my persona. And I need to pick one that makes sense for me and hold on to it, come hell or high water. People started jumping into the beta channel just to snag their “ideal” username. I’ve seen some even sacrificing their entire chat history on the desktop client just to be able to set a username using the beta client. It’s almost humorous, and admittedly quite entertaining to watch all of this unfold. I don’t mean to hate on people rushing to get their hands on a Signal username, like a crowd plowing through a Walmart glass door to swoop a juicy Black Friday deal. I’m one of them! I’ve been following the development of this feature for years, and I know most of the technical details and intricacies. So I’m well aware of the intended use of usernames in Signal. Yet, I still fell for the FOMO.

Wrap Up

#

We’ve briefly touched on Signal’s new Usernames and Phone Number Privacy features. We saw how despite Signal’s extensive explanation of the intention behind usernames, people, including myself, couldn’t help but let their emotions take over and scramble to score a “nice” username. Now, I’d love to hear from you. Are you among the I-want-a-shiny-username crew? Or you’re part of the one-username-per-invite gang? Feel free to respond on Mastodon. See you there!

Level 1: Picking a Home

#

As a newcomer to Mastodon, the first step is to select a server, also known as an instance. Mastodon is built upon a federated model, meaning that it consists of multiple interconnected servers rather than one centralized platform. Each server has its own community, rules, and moderation policies. This decentralized structure empowers users with the ability to choose an instance that aligns with their interests and values.

During this stage, it’s essential to research and understand the ethos of different instances. Some instances cater to specific topics or themes, such as art, technology, or activism, while others focus on fostering a safe and inclusive environment. By picking the right server, you can easily connect with like-minded individuals and immerse yourself in communities that resonate with your passions.

It’s worth noting that the decision of picking a server is not permanent or binding. Mastodon allows users to seamlessly move their account from one server to another. If you find that your chosen server doesn’t meet your expectations or you wish to explore new communities, you can easily migrate your account to a different server without losing your followers or the people you follow¹. This flexibility ensures that even if you initially choose a server that doesn’t align perfectly with your preferences, it’s not a big deal, and you have the freedom to make adjustments as you explore the Mastodon ecosystem.

At this point, you have pretty much everything you need to get started on Mastodon. Using the official website or mobile app, you can set up your profile, post your first toot², which I recommend be an introduction post, and start exploring the platform. However, if you’re looking to take your Mastodon experience to the next level, you can consider other third-party apps that offer additional features and customization options. We’ll explore this in the next section.

Level 2: Experimenting with different apps

#

There are many third-party apps available for Mastodon, like Tusky and Tooot on Android, or iceCubes and iMast on iOS, that offer intuitive interfaces and a range of features that could enhance your experience. Experimenting with different apps allows you to find one that suits your preferences in terms of user interface, customization options, and additional functionalities.

As you delve into different apps, you’ll discover features like customizable timelines, advanced search options, and the ability to mute or block specific users or keywords. By familiarizing yourself with these features, you can tailor your Mastodon experience to suit your individual needs and preferences.

I personally haven’t evolved past this level, and I’m sure most people won’t either. However, if you’re looking to take your Mastodon experience even further and gain more control over moderation policies, server versions, data, and more; you can consider hosting your own instance which we’ll turn to in the next section.

Level 3: Hosting Your Own Single-User Instance

#

At this stage, you have the opportunity to take complete control over your Mastodon experience by hosting your own single-user instance which allows you to personalize your Mastodon environment to your exact specifications.

By hosting your own instance as a single user, you gain unparalleled freedom and flexibility. You become the sole administrator of your instance, allowing you to define the rules, moderation policies, and themes according to your preferences. With this level of control, you can curate a space that truly reflects your values and interests.

One of the major advantages of hosting your own single-user instance is the ability to customize the appearance and functionality to suit your needs. You can tailor the instance’s design, branding, and features to align perfectly with your personal style and requirements. Whether it’s the color scheme, layout, or additional functionalities, you have the power to shape your Mastodon experience exactly the way you envision it.

Hosting your own instance also eliminates any concerns about relying on external servers. You have full autonomy over the server maintenance, ensuring optimal performance, security, and data privacy. It goes without saying that hosting your own instance does require technical knowledge and resources, as you will be responsible for server setup, maintenance, and regular updates.

It’s worth clarifying that being the sole user of your instance doesn’t prevent you from engaging with others, and building your online presence. While your instance doesn’t aim to build a community, you can still connect with other users as if you were all on the same server.

Now, you don’t have to stop here. While hosting your own single-user instance is more than what most people will ever need, you can take it a step further and open your instance for registration to welcome other users. We’ll explore this in the next section.

Level 4: Fostering a Community

#

As you continue to explore Mastodon and expand your reach, you may consider opening registration for users on your instance, with the intention of fostering a community around shared interests and values.

By opening registration, you provide an opportunity for people who resonate with your content or the community you aim to build to join your instance and participate. This step allows you to create a space where individuals with similar passions can connect, collaborate, and engage in meaningful discussions.

As the administrator of your instance, you have the power to shape the community by defining the rules, themes, and moderation policies. Encourage respectful and constructive interactions, foster a supportive environment, and create spaces for people to share their thoughts, ideas, and creations.

Additionally, by welcoming others to your instance, you not only create a space for like-minded individuals to connect but also contribute to the decentralization and scalability of the Mastodon network. In a decentralized ecosystem like Mastodon, distributing the user load across multiple instances is crucial to ensure stability, performance, and avoid instances becoming overcrowded. Opening your instance to newcomers allows for a healthier distribution of users across the network, preventing the concentration of a large user base on a few instances. This decentralization is key to maintaining a vibrant and sustainable Mastodon community.

Wrap Up

#

Mastering Mastodon is an exciting journey that unfolds across different stages of proficiency. From selecting the right server to exploring various apps, hosting your own single-user instance, and potentially fostering a community, each level offers unique opportunities to shape your Mastodon experience. Embrace the flexibility, connect with others, and discover the diverse communities within Mastodon. Whether you’re seeking an alternative to traditional social media or championing privacy and inclusivity, Mastodon has something to offer at every step of your personal mastery. So, embark on this journey, make meaningful connections, and let Mastodon become your digital haven.

One of the main reasons why blogs don’t need a database is that they are typically static websites. This means that the content on the website does not change frequently and isn’t customized for any particular visitor, and the website does not require any user interaction. In such a case, a database would be unnecessary as the information on the website can be stored in the form of HTML and CSS files.

Before going further, if your website has any dynamic functionality like user registration and login, or first party comment support, you’re out of luck and there’s no way around using a database; unless you’re feeling adventurous enough to delegate those functionalities to third party providers and hook your website onto them solely through the frontend. This adds a bit of complexity and calls for some technical knowledge though, which voids some of the benefits of static websites. Maybe you don’t need those dynamic functionalities to begin with and might be better off without them. Food for thought.

The Old School

#

The traditional method of running a blog is by utilizing a database to store the articles and a server-side script that dynamically generates the pages upon a user’s request. This method, commonly referred to as a “dynamic” approach, has been the prevalent norm for a considerable duration. However, this has several drawbacks.

First, the energy consumption is a paramount concern. Databases necessitate a substantial computational capacity, and oftentimes, they are run on servers that consume copious amounts of energy. This energy consumption leads to a substantial carbon footprint, thereby exacerbating climate change. Furthermore, the servers that host these databases are usually situated in data centers, which consume substantial amounts of energy to cool the servers and keep them operational. In addition, databases are frequently over-provisioned and underutilized, resulting in the squander of resources. This is a direct result of the fact that a database must be able to handle the peak load, even though the actual load is frequently much lower. This is a significant waste of resources, both in terms of energy and hardware.

Another drawback of using a database is the cost. Hosting a dynamic blog requires a powerful server, as well as a database. This can be expensive, especially for personal blogs which are not typically meant to generate revenue. Additionally, the more traffic a blog receives, the more powerful the server must be, and the more resources are required to handle the traffic. This can make it difficult for a blog to scale, and can also be a significant barrier to entry for those who are just starting out and do not have a lot of resources.

The third drawback of using a database is the slower page load times. When a user requests a page on a dynamic blog, the server must first query the database to retrieve the data, and then execute the server-side scripts to generate the page. This process takes time, and the more traffic a blog receives, the longer it takes to generate the pages. This can lead to a poor user experience, and can also negatively impact the blog’s search engine rankings.

The Hot New Thing

#

An alternative approach is to use a statically generated blog, which pre-generates all the pages and serves them as plain HTML and CSS files. This approach has several advantages over using a database besides the obvious benefits of not carrying the aforementioned drawbacks.

First, since the pages are pre-generated, they can be served directly by a web server without the need for any dynamic processing. This means that the hosting costs are lower, as you don’t need a powerful server or a database. Additionally, the static pages can be served directly by a Content Delivery Network (CDN), which can further reduce the hosting costs, and are often cached by the browser which also improves the page load times.

Another advantage of using a statically generated blog is the ability to generate pages offline. With a dynamic blog, the pages are generated on the fly, which means that the server must be online and accessible in order for the website to function. With a statically generated blog, however, the pages can be generated offline, and then uploaded to the web server. This can be useful for testing and brings a high degree of portability. Given that the website is nothing but static files, you can almost instantly move your website from one hosting provider to another.

The third advantage of using a statically generated blog is the increased security. With a dynamic blog, there is always a risk that the server-side scripts or the database could be hacked, which could potentially lead to sensitive information being compromised. With a statically generated blog, on the other hand, there is no server-side script or database to hack, which reduces the risk of a security breach.

I Don’t Want To Deal With HTML And CSS

#

If the thought of having to manually create and manipulate HTML and CSS files makes you sweat, don’t you worry. Using a statically generated website doesn’t mean that you need to become an proficient frontend developer. There are tools, so called static site generators (SSG), that allow you to create your blog using simple text files, such as Markdown, and then generate the necessary HTML and CSS files. This means that you can exclusively focus on creating content and customizing the design of your blog, by leveraging off-the-shelf themes.

One of the most popular SSG is Jekyll, which is written in Ruby. Jekyll takes your content, written in Markdown or Textile, and uses layouts to create a static website. Jekyll also supports data files, which can be used to store data in a structured format, such as YAML or JSON, that can be accessed in your templates.

Another popular SSG is Hugo, which is written in Go. It is a fast and flexible tool that can be used to build a wide variety of websites, including blogs. Hugo uses markdown files to generate your website, and it supports data files and template variables, which can be used to store and access data in a structured format.

It goes without saying that there are many more static site generators to choose from. Once the static website files are generated, they need to be hosted by a web hosting provider for the website to go online and be accessible from the internet. Here again, there’s no shortage of web hosting providers on the market. In fact, many would even be happy to host your static website for free! Providers like Netlify, Codeberg Pages, Github Pages, and Vercel immediately come to mind but I’m sure there are plenty others.

Wrap up

#

In today’s world, environmental sustainability is a top priority. And when it comes to blogs, statically generated sites are the clear winner. They require less energy and computing power, are much more secure than their dynamic counterparts, and are much easier to maintain. While I doubt that we can solve all our climate problems by making blogs static, I do believe that every bit of contribution towards that goal helps, however minute it seems. So if you’re looking to reduce your environmental impact and create a secure, cost-effective blog, be sure to go static!

The Beginning

#

My journey with digital note taking started with whatever default notes app happened to be on my phone. At first, I didn’t have any particular framework for note taking; it was just a random collection of digital post-it stickers. Similar story on the desktop, a structureless heterogeneous cluster of text files scattered all over the place.

Then, I started taking notes more seriously (pun intended) to capture knowledge, such as book summaries and highlights, things I learn from videos and documentaries, new vocabulary I come across, random ideas or questions I want to get answers to, and more. Before you know it, my notes catalogue started getting a bit heavy and it was apparent that I needed some sort of framework to better tag and organize all that knowledge. At the time, Evernote was the new kid on the block and it had some attractive features, so without putting much thought into it, I created an account and poured all my notes over to it.

I used Evernote for a long time, longer than I would want to admit. But one day, shortly after I’d begun getting serious about my online privacy, I had a “Oh shit!” moment that I still remember to this day.

The Rabbit Hole

#

I geared up and I ventured down the rabbit hole of privacy-friendly, and open-source, note taking apps. I set a few criteria to guide my expedition:

1. The service has to be free of charge, or offer a free plan;
2. It has to be offline and/or support end-to-end encrypted backup and/or sync; and
3. It must respect user privacy, so no tracking, ads, or telemetry.

If there’s one thing I would never accept, it would be having my notes up in the cloud in the clear¹, may that be temporarily for synchronization or permanently for backup. My notes hold so much information about me, from future plans, to areas of interest in life, to just general knowledge. I bet that even my IQ could be deduced with a reasonable degree of certainty using the right AI model. Now that I think of it, I would definitely see myself in the future training a model on my notes and delegating some decision making to it: a tailored virtual assistant of sort. I’m no AI expert and this does seem far-fetched today, but I wouldn’t be surprised if it were a thing even half a decade from now. Anyway, I digress.

During my research, StandardNotes stood out as a good candidate with its end-to-end encrypted backup and sync, and focus on privacy. It seemed to check all the boxes, so I gave it a shot. I created a free account and, once again, migrated all my notes off of Evernote into my StandardNotes account. I have to admit that this immediately felt like a downgrade; the feature set of StandardNotes’ free tier is rudimentary at best. But in the name of privacy, I sucked it up and worked around the limitations for a while. Thinking back, I realize that this was more of a “stop the bleeding” step than a permanent solution. Case in point, I never actually stopped exploring the free and open source note taking space for better options. Then, I came across Joplin.

At first, Joplin’s UI/UX looked out-dated, especially on mobile devices, but I was willing to be more lenient given that it’s a free and open source software maintained by a handful of generous people. What grabbed my attention was its self-hostable end-to-end encrypted capability. So I downloaded a copy of the app, set up a WebDAV server to handle the sync, and migrated all my notes over. After a few weeks of me getting used to its archaic UI, Joplin began setting itself as my permanent note taking solution. I started tinkering with various plugins, and even looked into making my own. All was great until the day the sync broke! My client was getting 503 errors from the sync server which corrupted some notes and rendered them unusable. Luckily, I had an offline backup of the affected files, so I managed to recover, albeit laboriously, from this crash. A few weeks later, another sync crash wiped my entire notebook. I wasn’t so lucky this time around, however, and ended up permanently losing some of my newer notes. This was the straw that broke the camel’s back. I couldn’t take it anymore; I had to find a better solution.

I decided to give StandardNotes another shot, but going with a self-hosted instance this time. This will ensure that I have full control over my notes’ backups, and that I enjoy a more decent set of features; or so I thought. So I migrated all my notes, once more, to my StandardNotes instance and started playing around with premium themes and extensions. The fact that a simple notes service required so many backend services, a.k.a micro-services, has never really sat well with me. I had the feeling that this level of complexity will eventually prove too cumbersome to maintain. And guess what? It did! After a recent update of the desktop client, my setup was brought to a halt. I was no longer able to connect to my self-hosted instance, running an old version of the server. It seemed like the new client version wasn’t backward-compatible and required a backend upgrade. When I tried to make that happen, I realized that the StandardNotes’ team overhauled their entire architecture. At this point, I wasn’t really down to learn the new setup, build new docker images, and get everything back online. It felt like a lot more work than a simple notes service should call for.

Refocusing

#

I took a step back, and went back to the drawing board. A quick cost/reward analysis confirmed that all of this friction wasn’t worth it. I realized that I didn’t really need the cross-device sync, since the vast majority of my notes fell under 2 categories: desktop, and phone. I seldom need notes from my phone when I’m on the desktop, and I almost never need notes from my desktop when I’m on my phone. So I decided to use 2 different note taking applications: vim with vimwiki for desktop notes, and my phone’s default notes app with cloud backup disabled. I suppose you know the drill by now: I migrated all of my notes, yes once again, from StandardNotes to vim and my phone’s default note app, hoping that this was the last time I perform this dance.

I’ve been driving this setup for weeks now and so far have a couple of takeaways. First, I’m struck by how pleasant it is to enter a typo’ed keyword into a search bar and watch the powerful fuzzy search engine instantly populate the page with extremely relevant results, the first one being the one I had in mind most of the time. I can’t remember a single time where this failed me. This made me realize just how mediocre, if not completely futile, StandardNotes’ search functionality was, particularly on mobile. Second, I never actually needed the cross-device sync or cloud backup for my notes. Offline backup, and segregated notebooks work just fine, check all the boxes with regards to privacy, and cost me practically no effort.

Before closing this off, I’d like to mention a couple other note services that I considered at some point, but wasn’t entirely sold on so I never took them for a test drive. Obsidian is more than just a note taking app. With its graph features and automatic note linking, it appears to be more of a knowledge management software; way more than I actually need for my personal use. Plus, the sync is a paid service with no option to self-host. Logseq is another solution that briefly caught my attention until I learned that it had no native sync support; the only way to sync data was to go through Github or iCloud.

Wrap up

#

If there’s a lesson to be drawn from this journey, it has to be that the most complex solution isn’t always the right one. I would argue that the simplest one turns out to be the best, more often than not. It just took me multiple migrations, hours if not days of tinkering around with various setups, and quite a bit of frustration wrestling with poor-UX software and dealing with lousy error handling, to realize it.

That being said, their introductory free tier leaves a lot to be desired. It could work for users with basic note taking needs but if you want to organize your notes in nested folders, use multiple editors like Markdown and Rich text, switch between a variety of themes, or schedule regular backups, you have to go with a premium plan. At $12/month, or $5/month if billed yearly, their cheapest plan is definitely at the higher end of the spectrum, especially that the service isn’t complex enough to warrant the hefty subscription fee in my view. It should come at no surprise if a Standard Notes subscription is considered a quite hard expense to justify by regular users who don’t fiddle with notes on a daily basis, or heavily rely on note taking in a professional capacity.

Fortunately, the Standard Notes team is nice enough to open source all their stack for anyone to self-host for personal use. On top of the obvious benefit of enjoying all the premium features free of charge, self-hosting comes with the advantage of full data control. The official documentation around self-hosting published by the Standard Notes team is clear and straightforward. They put together a docker-compose file that defines the entire stack along with a convenient script to create configuration files, bring the stack up and down, view logs, and more.

Thanks to the power of containers, you can be up and running in a matter of minutes, unless you’re running an ARM chip like a Raspberry Pi. Sadly, Standard Notes don’t provide official Docker images for ARM processors. You can either pick one of the third-party images made available by random users, or build your own. I tend to go with the latter option because it grants more control over the software version packed in the image, and most importantly it obviates the inherent security risk that comes with running untrusted Docker images¹. In the next section, we’ll go over the steps to build Docker images from source compatible with ARM processors, or any target architecture for that matter. If the official Docker images work on your processor architectures, feel free to jump straight to the “Premium extensions” section.

Building Docker images for ARM

#

First, we need to pull the code of the service we want to build a Docker image for. Let’s go with the auth service.

git clone https://github.com/standardnotes/auth

Then, from within the auth folder, let’s switch to the latest tag, or any other target version you want to use:

cd auth
git checkout 1.46.1

If you’re not sure what’s the latest tag, you can either check it directly on Github or list all available tags using:

git tag --list

If you’re building the image on the same machine that’s going to ultimately run the container, all you have to do is run a typical Docker build command like:

docker build -t arm-auth:1.46.1 .

However, if you’re building the image on a separate machine, perhaps because your server doesn’t have enough resources to carry out the build process, you can target a specific CPU architecture using buildx. Here’s what the command would look like:

docker buildx build --platform linux/arm/v6 -t arm-auth:1.46.1 . --load

Here, we’re targeting the version 6 of ARM and tagging the image with arm-auth:1.46.1. If you’re running a different version of ARM make sure to update the --platform flag accordingly.

As a side note, this will only work if linux/arm/v6 is loaded in the current buildx builder. To check the platforms supported by your buildx builder, run:

docker buildx ls

If your target platform is not currently loaded in buildx, try running a binfmt container like the following:

docker run --privileged --rm linuxkit/binfmt:a17941b47f5cb262638cfb49ffc59ac5ac2bf334

Now that the image is built, we need to move it to the server where it’s supposed to run. To do so, we first need to save it in a tar archive using the following command:

docker save arm-auth:1.46.1 -o arm-auth.tar

Then, after transferring it to the server via rsync, a USB key, or whatever other means deemed most convenient, we should load it on the server using:

docker load -i arm-auth.tar

Now, if we list all Docker images using docker images we should see our new arm-auth image. All that’s left to do is reference this image inside the standalone docker-compose file provided by Standard Notes.

It goes without saying that all the steps we’ve gone through in this section would need to be repeated for each one of the official Standard Notes services, which currently are:

• syncing-server-js;
• api-gateway; and
• files.

On top of their own services, Standard Notes use Redis for cache and MySQL for storage. The latter can be replaced with a MariaDB ARM image like linuxserver/mariadb while the former can be used as is; it already has a Docker image for ARM.

Premium extensions

#

Once your self-hosted Standard Notes instance is up, you can connect to it by pointing your Standard Notes client to your instance, under the “Advanced” section of the account creation or login view. You first need to create an account, which will be a “Basic” one by default, equivalent to the free tier. To be able to use premium themes and editors you need to upgrade your account with a couple of commands. Unfortunately, having a premium account in your self-hosted instance doesn’t automatically give you access to premium themes and editors. Standard Notes don’t give out their official premium extensions for free but you can load other community-built alternatives. Here are a couple of sources to get you started:

• https://snexts.github.io/
• https://github.com/jonhadfield/awesome-standard-notes

To load an extension, head over to your desktop client under Preferences > General > Advanced Settings. Then, enter the extension URL in the “Install Custom Extension” input field and hit “Install”.

Wrap up

#

Self-hosting Standard Notes is strikingly straightforward, barring few extra steps that require some Docker knowledge when working with an ARM chip. In this article, we’ve gone over everything needed to setup a Standard Notes server that’s not covered in the official documentation.

If you have any questions or face difficulties with the instructions laid out above, feel free to reach out on Mastodon.

Using a sound browser will go a long way in mitigating the risk of privacy violations. Like anything else in life, it’s important to use the right tool for the job. If you’re going on a road trip across the country, you’d want to drive the right vehicle, have spare tires, make sure the engine is healthy and won’t overheat, plan charging breaks if you’re going electric, and so on. The same applies to browsing the internet. In this article, I’ll go over different security and privacy measures implemented in Firefox, my favourite browser.

Before we dive in, let me note that my decision to run Firefox as my daily driver is not a political one or based on Mozilla’s management, work conditions, or product line. I’m only focused on the software itself and how it serves my personal internet browsing needs.

HTTP header sanitization

#

In this day and age, web pages have become remarkably complex to the point where it’s quite rare to find web services that don’t pull resources from other domains, may they be fonts, images, videos, scripts, or other types of resources. When a browser goes out to fetch external resources, it attaches the original URL to every request in the HTTP Referer header. The entire URL that the user had initially put in their browser address bar ends up transmitted to all the domains that the page being visited depends on. To give you an idea, if a user was reading an article on a news site in dark mode with big font (URL: https://www.allthenews.com/breaking-news-read-now?mode=dark&font-size=big); and this site loaded “share” buttons from Google, Twitter, and Facebook; all of these companies would be made aware of the article the user was reading and the preferred settings for article consumption.

Firefox trims the path and query parameters from the HTTP Referer header for all cross-origin requests by default. So in our previous example the URL would be turned into https://www.allthenews.com/ when communicated as a referrer to Google, Twitter, and Facebook, thereby reducing the amount of leaked user information.

Cookie store isolation

#

When it comes to cookie management, Firefox has really stepped up their game. I don’t think any other browser handles cookies nearly as well. Firefox not only blocks cookies from domains that were identified as trackers, it totally cripples cookie-based tracking with its Total Cookie Protection. It works by operating completely isolated cookie jars, each dedicated to a website that the user explicitly visited. By way of illustration, cookies set when the user visits website A are only ever attached to requests triggered by user actions on website A, including third-party cookies. This is exceptionally powerful because it means that a third-party cookie coming from Facebook, for instance, while browsing a news site will never make it back to Facebook when browsing any other website that uses Facebook’s assets.

In addition, Firefox’s Enhanced Cookie Clearing (ECC) allows you to wipe out all the data that were created by a specific website. This includes first and third party cookies, local storage data, settings, and cache. This is different than the typical “delete website cookies” setting you’ll find in other mainstream browsers in that ECC not only deletes data that belong to the selected website, but also all other data that were saved in your browser while visiting that website. Let’s say you’re on recipes.com that pulls in some assets from google.com, while also being directly logged into google.com in a separate tab. Clearing cookies of recipes.com using ECC will have the following effects:

• Delete all the data created by recipes.com
• Delete all the data created by google.com while browsing recipes.com. This means that we’ll remain logged into google.com in the second tab. This is extremely potent as it grants you the ability to make your browser effectively forget about all your activity on a given website.

Process isolation

#

Every time you visit a website with Javascript enabled, you run code that you’ve most likely never seen on your computer¹. The vast majority of browsers do a great job containing this code in a tight sandbox to prevent malicious out-of-scope access, but not all enforce good segregation within the sandbox. Firefox goes to great lengths to isolate code pulled from the internet that runs on your machine. With its Site Isolation, also called Project Fission, each website is loaded in a separate Operating System (OS) process. So if you visit “example.com” and, in a new tab, load “example.org”, these 2 websites’ code will run in 2 OS-segregated processes, each with its own isolated memory. And this isn’t specific to tabs; if “example.com” had an iframe that loaded content from “example.org”, the same thing would happen: Two processes would be spawned, one for each domain. This drastically improves protection against timing attacks like Spectre and Meltdown where one process can illegitimately peek into another’s memory. To see Firefox processes type “about:processes” in the address bar and hit “Enter”.

Moreover, Firefox is smart enough to also account for Public Suffix List² domains where multiple sites can be served as different subdomains of the same domain. For instance, if you were to load “my-site.codeberg.page” and “another-site.codeberg.page”, they would each get a separate process because they would be considered two different websites even though they share the same domain, since this domain is part of the Public Suffix List.

Session isolation

#

Now, let’s go up a few layers and look at what Firefox does at the session level. While there’s no built-in session separation beyond Private Browsing in Firefox, their team has built the Multi-Account Containers add-on which takes compartmentalization to the next level. Every container is a fresh browser session with its own storage and cookie store. Think “Private Browsing” but not limited to a single private session. This is particularly convenient when you want to log into multiple accounts on the same website. Furthermore, all the security and privacy measures we touched on so far are maintained inside each container. When you first visit a website in a container, Firefox remembers that and asks you the next time around if you’d like to assign that website to that container. Replying yes makes Firefox always open that website in the chosen container without you having to do so every time. Who said you had to pick between privacy and convenience again?

You can also set a separate Virtual Private Network (VPN) per container. For example, if you want to use a VPN when shopping online you could create a “shopping” container and configure it to always use your VPN³.

Profiles

#

To push compartmentalization even further, Firefox allows you to manage multiple profiles within the same installation. A profile is nothing more than a set of user information, like bookmarks, saved passwords, settings, etc. While using profiles is generally not needed, there are few cases where it comes in very handy. Imagine dealing with a website that doesn’t work properly with Firefox strict tracking protection mode, which you should always have on by the way. You could, short of ditching that website and finding a better alternative, spin up a new profile where you don’t use strict tracking protection mode for the sole purpose of visiting that website. This can apply to anything that’s not impacted by the Multi-Account Containers add-on like bookmarks, extensions, and themes.

Wrap up

#

Well that was a lot of material! We’ve covered various security and privacy features that come with Firefox out of the box, in addition to an add-on that brings a new dimension of compartmentalization to the mix. Things like cookie store, session, and process isolation; HTTP header sanitization; and more. In my view, this makes Firefox the best browser, at the time of this writing, for a privacy-conscious internet user like myself.

If you know a free and open-source browser that offers all the guarantees mentioned in this article, please bring it to my attention; I’d love to see how it compares to Firefox.

In this article, we’ll learn a bit about DoH with a quick refresher on DNS and how it works, and go over a few strategies to improve online privacy by securing DNS.

What’s DoH?

#

The Domain Name System (DNS) is the system used to identify computers on the internet. Computers can only communicate with one another if they know each other’s IP addresses. But IP addresses, which are basically a bunch of numbers bundled together, are hard to memorize. If we had to use IP addresses to access websites, the web wouldn’t have taken off the way it did and you wouldn’t be reading this article online today. DNS was invented to accommodate humans, not machines.

Every time you type a URL in the browser, it issues a DNS query to your DNS server in order to resolve the IP address of the website you’re trying to visit. The same thing happens when you open an app on your mobile device, when your smart light bulb phones home to fetch the most up-to-date brightness level it should shine at, and when you add a new show to your list on your smart TV Netflix app. Basically, every single action you make online triggers one or more DNS queries.

However, DNS was not built with privacy in mind. All DNS queries are routed through the internet in plain text. This means that anyone sniffing traffic on a network, or acting as a proxy to the internet, like an ISP or an enterprise router, can see the web locations that everyone on that network is visiting. While watching DNS traffic alone doesn’t give out information about the interactions between a client and a given website, it does paint a detailed picture of the web locations that a user has visited, an estimate of how long they have been on each website, the apps they’re using, and the type of Internet-of-Thing (IoT) devices they have installed in their homes, if any. It goes without saying that this is extremely detrimental to one’s online privacy. Fortunately, there are solutions to this problem.

One way of protecting one’s DNS queries from snooping eyes is to use encryption, like with DNS over TLS (DoT) or DNS over HTTPS (DoH). In this article we’ll focus on DoH which routes DNS traffic in an encrypted HTTPS tunnel. The client establishes a secure connection with the DNS server and funnels all DNS queries through it. This effectively encrypts DNS communications and renders them inaccessible to spying third parties. Now, let’s explore a few options of leveraging DoH to protect online activities¹ and improve privacy.

Client Settings

#

Many browsers² nowadays offer the option to configure a custom DoH server. However, this kind of configuration only applies to the activity happening in the browser and as mentioned previously, not all web requests originate from a browser. If we want to protect all DNS traffic emerging from a network, say a user’s home network, we should configure the network to use a local DNS server under our control that will turn around and delegate DNS resolution to a trusted upstream provider using DoH. First, let’s see how we can build this local DNS server.

Local DNS Server

#

Cloudflare built a nice little application called cloudflared that converts plain DNS queries to DoH. It’s free, open-source and easy to run. If you’ve read any other post on this blog you must’ve realized how much I love containers. So let’s build a cloudflared Docker image to run as a local DNS server. Unfortunately, Cloudflare doesn’t offer an official Docker image for cloudflared but we can make our own fairly easily. To do so, in a file named Dockerfile put the following content:

1FROM alpine:3.15
2
3RUN apk add --no-cache bash
4
5RUN wget -q https://github.com/cloudflare/cloudflared/releases/download/2022.1.2/cloudflared-linux-arm \
6	&& chmod +x cloudflared-linux-arm \
7    && mv /cloudflared-linux-arm /usr/local/bin/cloudflared

Here, we’re using alpine version 3.15 and cloudflared version 2022.1.2 but more versions might have been released since this article was published. Feel free to update these versions to the latest.

In order to use this Docker image we can build a docker-compose service to run cloudflared. Alongside the previously created Dockerfile, let’s make a new file called docker-compose.yml with this content:

 1version: "3.8"
 2
 3services:
 4  cloudflared:
 5    build: .
 6    ports:
 7      - "53:5053"
 8    # replace <UPSTREAM SERVER> with the URL for the upstream DoH server
 9    # e.g.: https://doh.libredns.gr/dns-query
10    entrypoint: bash -c "cloudflared proxy-dns --port 5053 --address 0.0.0.0 --upstream <UPSTREAM SERVER>"
11    restart: unless-stopped

Make sure to replace <UPSTREAM SERVER> in the entrypoint command with your DoH server of choice. PrivacyGuides lists a few options you can pick from if you don’t already have a favourite DNS server. At this point, you have everything you need to convert all DNS queries in your network into DoH. Here are the steps to accomplish this:

1. Run docker-compose up cloudflared from the folder where you put the Dockerfile and docker-compose.yml files to spin up a cloudflared container. Ideally, this should be done on a machine that’s constantly running on your network with a static IP address. A Raspberry Pi or a home server are great candidates for this.
2. Configure your network’s DHCP server to use the machine where cloudflared is running as its default DNS server. This will automatically instruct all devices on the network to use the cloudflared container for DNS resolution. If you don’t have control over your DHCP server, or it’s too complicated to reconfigure at the moment, you can always start off by manually editing the DNS configuration on your most-used devices.

DoH in Pihole

#

If you already have a Pihole docker container running in your network and serving DNS queries, you can now set the cloudflared container as an upstream DNS server in Pihole and automatically upgrade all DNS queries to DoH. We’ve seen in a previous article how to set up Pihole using Docker. We’ll use the same docker-compose file here to illustrate how to integrate cloudflared.

First we need to place the Dockerfile file we created in the previous section inside a folder called cloudflared. Then, using our previous Pihole docker-compose file, we can add a new service for cloudflared as shown below:

 1version: "3.8"
 2
 3services:
 4  pihole:
 5    # ...
 6    environment:
 7      # ...
 8      - PIHOLE_DNS_=172.31.0.200#5350
 9    # ...
10    depends_on:
11      - cloudflared
12      - dhcphelper
13    # ...
14
15  dhcphelper:
16    # ...
17
18  cloudflared:
19    build: ./cloudflared
20    environment:
21      # set UPSTREAM_PROVIDER to the URL for the upstream DOH server
22      # e.g.: https://doh.libredns.gr/dns-query
23      - UPSTREAM_PROVIDER=
24    entrypoint: bash -c "cloudflared proxy-dns --port 5053 --address 0.0.0.0 --upstream $$UPSTREAM_PROVIDER"
25    networks:
26      backend:
27        ipv4_address: '172.31.0.200'
28    restart: unless-stopped
29
30networks:
31  # ...
32
33volumes:
34  # ...

You’ll notice that the cloudflared service looks similar to the one we built in the previous section. Here, we don’t need to expose the port 53 to the host because the only client connecting to the cloudflared container is the Pihole container running in the same Docker network. Also, we have to set a static IP address for the cloudflared container and add it to the PIHOLE_DNS_ environment variable of Pihole in order for it to be used as an upstream DNS server.

With the modifications above, restart your Pihole container by running docker-compose down and bringing it back up with docker-compose up pihole, and you should have a cloudflared container running alongside Pihole, ready to receive requests.

Wrap up

#

Congratulations, you made it! You now understand why protecting your DNS traffic is paramount to improving your online privacy and have in your toolbox 3 strategies for doing so, some more potent than others. In case you can’t run a full-fledged Pihole and cloudflared setup on your network, or don’t have the time to set that up yet, at least configure your most-frequently-used browser to resolve DNS through DoH. It takes almost no time, and goes a long way in getting you to a better place when it comes to your online privacy.

First Password Manager

#

My journey with password managers started way back when I used the “save password” feature in the Chrome browser. I was still “generating” passwords myself but relying on Chrome to save and automatically insert them when I’m on the login page of various websites. At that time, I didn’t really have too many accounts - probably no more than a dozen. But as the web started turning into a plethora of sign-up walls, where you can’t hover on a button without having to log in first, I quickly ran out of ideas to create new unique passwords. This is the point where I knew I needed a proper password manager.

Around this time, Lastpass was one of the most dominant actors in the field of password management and they were doing some good work. So I decided to give Lastpass a try and I really liked it. The convenience of not having to come up with a “secure” password that I haven’t used before when signing up on a new website, brought such a relief to my account creation flow and reduced a considerable amount of friction. Lastpass had some issues however. The data breach of 2015 was the first thing to sound the alarm for me. I started to realize that fully trusting an entity with my most valuable data, the keys to every single account I own, was probably not a good idea. To make matters more scary, Lastpass does not publish their source code for others to view, analyze, and even contribute to. Security by obscurity is never the way to go. Furthermore, they include third-party trackers in their codebase which is a very bad practice for a security-critical service like Lastpass.

I’m not trying to sabotage Lastpass here, or imply that their security is lacking. As a matter of fact, their security model seems to be solid. As far as I know, there has never been any breach that exposed user sensitive data like passwords in clear text. All I’m saying is that it wasn’t the right fit for me. Not to mention that their recent up-sell push to convert free users to premium by restructuring their pricing and feature models just didn’t sit right with me. They were turning into another Big Tech player, and it was time for me to walk away.

Gaining back control over my data

#

When I started using Lastpass, there weren’t many options to choose from. But few years later, other password managers started popping up and one of them was particularly good at distinguishing itself amongst the privacy-focused community. This password manager is no other than KeepassXC. I believe it’s the first open-source password manager that I was made aware of and I instantly fell for it. It’s a free, community-driven, offline password manager that I simply couldn’t ignore. Next thing you know, I was migrating all of my passwords off of Lastpass and celebrating the addition of yet another open-source tool to my arsenal.

The only problem that I had to solve was synchronizing data across multiple devices. With a cloud-based service like Lastpass, this issue is taken care of by the service itself and changes on one device are replicated across the others automatically. With an offline password manager like KeepassXC on the other hand, data synchronization becomes the responsibility of the user. So, I moved all my credentials to a KeepassXC database (DB), and used a cloud service to regularly back it up. When I needed a fresh version of my DB in any of my devices, I either transferred it directly within my home network, or pulled it from the cloud service provider, and used an open-source client to read it. To make things simple, I also only ever made changes to the DB on my computer, and stuck to read-only mode on the other devices. You can imagine how this could sometimes prove tedious, especially when I needed to update existing or create new entries in my credentials list from a device other than my main computer. I started to seriously miss the convenience of the seamless synchronization I enjoyed with Lastpass, but I wasn’t ready to downgrade my security and privacy just for that.

The best of all worlds

#

Luckily, there was this new kid on the block, a new solution that ticked all the boxes for me - it’s open source, free¹, and self-hostable! This meant that I could get all the benefits of data control I have with KeepassXC and the convenience of seamless multi-device synchronization. The solution I’m referring to is Bitwarden. Ever since I launched my own instance of Bitwarden, I’ve never looked back. I truly love this piece of software and am so grateful to the amazing people behind it. Plus, the beauty of it all is that when you host your own instance you get all of the premium features for free!

Wrap up

#

As you see, I wasn’t fortunate enough to pick a winner right from the start. I began my journey naive, prioritizing convenience without paying much attention to security, let alone privacy. As I learned more about password managers, I shifted my priorities and started giving more weight to security and privacy, even at the expense of convenience at times.

If you have comments or suggestions, or if you just want to strike a conversation on this topic, feel free to hit me up on Mastodon.

Docker setup

#

Let’s start by setting up a docker-compose.yml file to run the Bitwarden server:

 1version: "3.8"
 2
 3services:
 4  bitwarden:
 5    container_name: "bitwarden"
 6    image: vaultwarden/server
 7    ports:
 8      - "3012:3012"
 9    volumes:
10      - data:/data
11
12volumes:
13  data:

Here, we’re using vaultwarden/server image which is a rust-based version of Bitwarden server. We’re exposing a TCP port to be able to communicate with the container from outside of Docker network. Then, we create a volume and mount it on /data inside the container. That’s where Bitwarden stores its data, including users, vaults, and attachments.

If we bring up this container and try to access Bitwarden through https://localhost:3012, it will not work. Bitwarden requires all communications to go through a TLS tunnel. In other words, we need to use HTTPS instead of HTTP. We’re going to use a second container running Nginx to handle TLS for us and proxy requests to Bitwarden’s container.

 1version: "3.8"
 2
 3services:
 4  bitwarden:
 5    # ...
 6    depends_on:
 7      - nginx
 8
 9  nginx:
10    image: nginx:1.21.0-alpine
11    ports:
12      - "23984:443"
13    volumes:
14      - ./nginx/ssl:/etc/ssl:ro
15      - ./nginx/conf.d:/etc/nginx/conf.d:ro
16    restart: unless-stopped
17
18volumes:
19  data:

In this configuration, we’re declaring a new service nginx using the alpine image of nginx, exposing a port so that the container can be reached from outside Docker’s internal network, and specifying a couple of read-only volumes. We’re also instructing Docker to automatically restart this container unless it was manually stopped. This can help increase availability by automatically recovering from sudden crashes.

The final result looks like follows. Notice that we introduced a environment variable ADMIN_TOKEN that can be used to access the admin section of Bitwarden. More on how to do this later.

 1version: "3.8"
 2
 3services:
 4  bitwarden:
 5    container_name: "bitwarden"
 6    image: vaultwarden/server
 7    environment:
 8      - ADMIN_TOKEN=SOME_SECRET_TOKEN
 9    volumes:
10      - data:/data
11    depends_on:
12      - nginx
13
14  nginx:
15    image: nginx:1.21.0-alpine
16    ports:
17      - "23984:443"
18    volumes:
19      - ./nginx/ssl:/etc/ssl:ro
20      - ./nginx/conf.d:/etc/nginx/conf.d:ro
21    restart: unless-stopped
22
23volumes:
24  data:

TLS Support

#

Now that we have our containers set up, it’s time to configure Nginx to handle TLS connections and forward them to Bitwarden’s container. Let’s create a server configuration file named bitwarden.conf and place it under nginx/conf.d/. This path is relative to wherever you place the docker-compose.yml file.

 1server {
 2    listen 443 ssl http2;
 3
 4    # Allow large attachments
 5    client_max_body_size 128M;
 6
 7    location / {
 8        proxy_pass http://bitwarden:80;
 9        proxy_set_header Host $host;
10        proxy_set_header X-Real-IP $remote_addr;
11        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
12        proxy_set_header X-Forwarded-Proto $scheme;
13    }
14
15    location /notifications/hub {
16        proxy_pass http://bitwarden:3012;
17        proxy_set_header Upgrade $http_upgrade;
18        proxy_set_header Connection "upgrade";
19    }
20
21    location /notifications/hub/negotiate {
22        proxy_pass http://bitwarden:80;
23    }
24}

This is a pretty typical Nginx proxy configuration where we define a port to listen to along with protocols we want to handle. Next, we have a directive to allow large attachments¹ and we declare a few paths and how they should be handled. We’re not going to dive into each directive used here but if you want to know more about how to configure Nginx, I encourage to check out their official documentation.

If you’ve been following along you’ll notice that we haven’t addressed the SSL connection yet, and without it our setup will not work. So let’s figure that out. In case you’re planning to use a real domain name for your Bitwarden instance, you can skip this section and jump directly to Nginx Configuration.

In order to make a self-signed TLS certificate, first we need to generate a private key and a certificate for our Bitwarden server using the following command.

OUT_FOLDER=/path/to/ssl
DOMAIN=your.bitwarden.domain

openssl req -x509 -nodes -days 365 -newkey rsa:4096 \
        -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:$DOMAIN\nbasicConstraints=CA:true")) \
        -keyout $OUT_FOLDER/private/nginx-bitwarden.key \
        -out $OUT_FOLDER/certs/nginx-bitwarden.cert \
        -reqexts SAN -extensions SAN \
        -subj "/C=US/ST=New York/L=New York/O=Company Name/OU=Bitwarden/CN=$DOMAIN"

This will generate a new public key nginx-bitwarden.key using RSA with a key length of 4096 bits, and a self-signed TLS certificate nginx-bitwarden.cert valid for 365 days in the private/ and certs/ folders respectively. These folders should be placed under the folder ssl/ that lives alongside our docker-compose.yml file, so make sure you set the $OUT_FOLDER variable properly. In addition, the $DOMAIN should be set to the fully qualified domain name of the machine where you’re planning to run Bitwarden and Nginx. It’s not complicated to assign an FQDN to your local machine using a local DNS, especially if you’re running Pihole. If you’re interested in getting Pihole set up locally with Docker, check out this article.

Nginx Configuration

#

Now that we have our certificate and private key, we should tell Nginx where they are located in order to use them for TLS connections.

1server {
2    listen 443 ssl http2;
3
4    ssl_certificate      /etc/ssl/certs/nginx-bitwarden.crt;
5    ssl_certificate_key  /etc/ssl/private/nginx-bitwarden.key;
6
7    # ...
8}

It’s recommended to generate a Diffie-Hellman file for stronger connections and use it in our Nginx configuration. We can generate one with the command:

openssl dhparam -out $OUT_FOLDER/certs/dhparam.pem 4096

To be honest, I haven’t yet looked at the functions of this Diffie-Hellman file to fully understand how it improves security. But if you know more about it and are interested in contributing your knowledge to this article, feel free to reach out to me on Mastodon.

The complete Nginx configuration after linking the .pem file should look like follows.

 1server {
 2    listen 443 ssl http2;
 3
 4    ssl_certificate      /etc/ssl/certs/nginx-bitwarden.crt;
 5    ssl_certificate_key  /etc/ssl/private/nginx-bitwarden.key;
 6
 7    ssl_dhparam /etc/ssl/certs/dhparam.pem;
 8
 9    client_max_body_size 128M;
10
11    location / {
12        proxy_pass http://bitwarden:80;
13        proxy_set_header Host $host;
14        proxy_set_header X-Real-IP $remote_addr;
15        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
16        proxy_set_header X-Forwarded-Proto $scheme;
17    }
18
19    location /notifications/hub {
20        proxy_pass http://bitwarden:3012;
21        proxy_set_header Upgrade $http_upgrade;
22        proxy_set_header Connection "upgrade";
23    }
24
25    location /notifications/hub/negotiate {
26        proxy_pass http://bitwarden:80;
27    }
28}

Finally, we have our containers configured to run Bitwarden. All we need to do in order to bring them up is run:

docker-compose up -d bitwarden

Once the containers are up, you’ll be able to reach Bitwarden through its domain name. Given our example configuration, that would be https://your.bitwarden.domain. The first time you open the page, your browser will most likely complain about an insecure connection and display a flashy warning. If it doesn’t, stop using this browser and get yourself a real one! This is due to the self-signed certificate. Since the certificate is not signed by a Certificate Authority (CA) present in the browsers or the OS’s root CA store, the browser considers the connection insecure. You can add an exception for this certificate in your browser so that it doesn’t freak out every time you access your self-hosted Bitwarden. Similarly, you will have to install this certificate on your device and trust it, otherwise the OS will prevent Bitwarden’s app to communicate with our running container. To do so, send the nginx-bitwarden.crt file we generated in the TLS Support section to your device², open it and follow the installation steps. It should be straightforward in most OS’s but it’s always safe to follow the official guide to make sure you cover all the steps. For instance, in iOS, on top of installing the certificate you have to explicitly trust it for TLS connections.

Admin Access

#

Like we’ve seen in a previous section, in order to unlock the admin panel we need to set a token in the ADMIN_TOKEN environment variable. Let’s generate a token using the following command.

openssl rand -base64 48

Once Bitwarden’s container is restarted after setting the admin token, you can access the admin panel at https://your.bitwarden.domain/admin.

Wrap up

#

We finally made it. We built a docker setup running a container for the Bitwarden server with an Nginx proxy handling TLS connections using a self-signed certificate. This grants us full control over our credentials and any other data we choose to store in Bitwarden, all without having to trust any third party to handle this for us.

Running Pihole on Docker is pretty straightforward, but things start to get a bit complicated when it comes to enabling DHCP - using Pihole to serve DHCP requests. With Docker’s default bridge network mode, we can’t use Pihole as a DHCP server. So we have two options: (1) use the host network mode, or (2) run a DHCP relay (more on this later).

Option (1) is the easiest because all we’d have to do is set network_mode: "host" in the service definition, but it comes with a considerable disadvantage. It undermines the network isolation provided by Docker’s bridge driver, not to mention that it will take up ports from the host’s network which could be a concern depending on what’s running on your server. Option (2) allows us to stick to the bridge mode but adds a good amount of complexity. If you’re anything like me, you’ll favor security and try to maintain Docker’s network isolation.

Option (2) it is. Make sure your cup of coffee is full, and let’s dive in!

Pihole on Docker

#

First, let’s build a docker-compose.yml file with a basic configuration to run Pihole.

 1version: "3.2"
 2
 3services:
 4  pihole:
 5    container_name: pihole
 6    image: pihole/pihole:latest
 7    ports:
 8      - "53:53/tcp"
 9      - "53:53/udp"
10      - "8080:80/tcp"
11    environment:
12      - TZ=America/New_York
13      - WEBPASSWORD=very-secure-password # Choose a password for admin
14      - PIHOLE_DNS_="1.1.1.1;1.0.0.1" # Set upstream DNS servers
15      - ServerIP="10.10.0.10" # Your host's external IP
16    volumes:
17      - pihole:/etc/pihole/
18      - dnsmasqd:/etc/dnsmasq.d/
19    restart: unless-stopped
20
21volumes:
22  pihole:
23  dnsmasqd:

In this example, we define a service called pihole using the official Pihole Docker image. Then, we publish a few ports to get DNS requests (UDP port 53) forwarded to the container running Pihole, and to allow access to the web panel (TCP port 80). After that, we set some environment variables:

• WEBPASSWORD¹: The password to use when logging into the admin panel.
• PIHOLE_DNS_: A semicolon separated list of upstream DNS servers. These are the servers Pihole will reach out to in order to resolve DNS queries.
• ServerIP: The external host IP. This is the IP that machines on the network will send their DNS queries to. In other words, this should be the host’s IP on the LAN network.

Last, we define a couple of volumes to persist configuration across multiple container restarts.

DHCP through Docker’s Bridge Network

#

At this point, we have a working Pihole deployment ready to manage DNS on the host’s network. Since we didn’t specify the network mode in the docker-compose file, the container is provisioned using the default driver: bridge network. This means that Pihole lives in a separate network than the host along with other machines on the LAN. Docker daemon bridges these 2 networks and forwards ports as specified in the docker-compose file. This works great for DNS, but not so much for DHCP. If we tried to enable DHCP on Pihole’s web interface, it would unfortunately not work. To understand why, let’s go over a brief overview of how DHCP works.

When a client joins a network it starts broadcasting a DHCP discovery request on that same network on UDP port 67. If there’s a DHCP server listening, it will respond to this request with a lease offer that the client then accepts². This is how machines get assigned IP addresses dynamically when joining a network.

DHCP is not routable however, so discovery requests don’t span across different networks. In our setup, since Pihole is running in a Docker container with bridge network mode, it lives in a separate network (Docker internal network) than the LAN, so DHCP discovery requests stop at the edge of the LAN and never make it to Pihole. To solve this, we need a DHCP relay connected to both the LAN and Docker’s internal network. It will intercept discovery requests on one network and forward them to Pihole on the other.

With the theory out of the way, let’s move on to a practical solution to our problem. We will use dhcp-helper as a DHCP relay. First, we create a small image with that package and place the Dockerfile in a folder called dhcp-helper.

1FROM alpine:latest
2RUN apk --no-cache add dhcp-helper
3EXPOSE 67 67/udp
4ENTRYPOINT ["dhcp-helper", "-n"]

The file content is self explanatory. We’re using an alpine image, adding the dhcp-helper package, exposing the UDP port 67 in order to receive DHCP discovery requests, and we’re running the helper command at startup.

The next step is to update the original Pihole docker-compose file to include the DHCP relay. We will need to add a service for the relay, an additional network with a fixed IP for the Pihole container, and make the Pihole service depend on the DHCP relay.

 1version: "3.2"
 2
 3services:
 4  pihole:
 5    container_name: pihole
 6    # ...
 7
 8  dhcphelper:
 9    build: ./dhcp-helper
10    restart: unless-stopped
11    network_mode: "host"
12    command: -s 172.31.0.111
13    cap_add:
14      - NET_ADMIN

Notice that we’re using the host network mode for the DHCP relay service. This is important if we want to intercept discovery requests on the same network as the host (LAN). Also, we’re adding a flag to the entry point command specifying the server’s IP. We’ll assign this IP to Pihole’s service as follows:

1version: "3.2"
2
3services:
4  pihole:
5    container_name: pihole
6    # ...
7    networks:
8      backend:
9        ipv4_address: '172.31.0.111'

In order to use this new network that we named backend we need to define it in our docker-compose file:

 1version: "3.2"
 2
 3services:
 4  pihole:
 5    container_name: pihole
 6    # ...
 7
 8  dhcphelper:
 9    build: ./dhcp-helper
10    # ...
11
12networks:
13  backend:
14    ipam:
15      config:
16        - subnet: 172.31.0.0/16

With all these modifications, we end up with the following docker-compose file:

 1version: "3.2"
 2
 3services:
 4  pihole:
 5    container_name: pihole
 6    image: pihole/pihole:latest
 7    ports:
 8      - "53:53/tcp"
 9      - "53:53/udp"
10      - "8080:80/tcp"
11    environment:
12      - TZ=America/New_York
13      - WEBPASSWORD=very-secure-password # Choose a password for admin
14      - PIHOLE_DNS_="1.1.1.1;1.0.0.1" # Set upstream DNS servers
15      - ServerIP="10.10.0.10" # Your host's external IP
16    volumes:
17      - pihole:/etc/pihole/
18      - dnsmasqd:/etc/dnsmasq.d/
19    restart: unless-stopped
20    depends_on:
21      - dhcphelper
22    cap_add:
23      - NET_ADMIN
24    networks:
25      backend:
26        ipv4_address: '172.31.0.111'
27
28  dhcphelper:
29    build: ./dhcp-helper
30    restart: unless-stopped
31    network_mode: "host"
32    command: -s 172.31.0.111
33    cap_add:
34      - NET_ADMIN
35
36networks:
37  backend:
38    ipam:
39      config:
40        - subnet: 172.31.0.0/16
41
42volumes:
43  pihole:
44  dnsmasqd:

One More Thing

#

So far, we’ve managed to:

1. Run a Pihole container with bridge network mode
2. Run a DHCP relay container that listens for discovery requests on the LAN and forwards them to Pihole on Docker’s internal network.

However, by default Pihole sends out leases instructing clients to use its IP as a DNS server. The IP used here is Pihole’s IP address on the network where it received the DHCP request. This means that the clients will be configured to send their DNS queries to an address on the network 172.31.0.0/16 and this will not work. This is an internal Docker network that we created to connect Pihole to the DHCP relay, and that machines on the LAN have no access to. In order to resolve this, Pihole needs to grant DHCP leases with the host’s external IP as the DNS. We can accomplish this by adding a configuration option to dnsmasq running inside Pihole’s container. This is as simple as creating a file inside Pihole’s container under /etc/dnsmasq.d/ with the following:

dhcp-option=option:dns-server,<PIHOLE_HOST_EXTERNAL_IP>

To make our lives easier, let’s put this in a script file called update-dhcp-dns and also support multiple DNS servers while we’re at it.

 1#!/bin/bash
 2
 3DNS_SERV_IPS="" # A comma separated list of DNS IPs. E.g.: "10.10.0.10,1.1.1.1,1.0.0.1"
 4
 5if [[ -z $DNS_SERV_IPS ]]; then
 6    echo "Please set DNS servers IPs by modifying the script file."
 7    exit 1;
 8fi
 9
10docker-compose exec pihole bash -c "echo 'dhcp-option=option:dns-server,$DNS_SERV_IPS' > /etc/dnsmasq.d/07-dhcp-options"

Wrap up

#

We finally have all the pieces we need to run Pihole in a Docker container with bridge network mode and have it serve DHCP requests on the host’s LAN. After updating docker-compose.yml and update-dhcp-dns with your desired configuration values, like the web password, server IP, and DNS IPs, you can deploy using the following commands.

docker-compose up -d pihole
./update-dhcp-dns

Note that you only need to run ./update-dhcp-dns once. The modifications introduced by this script will persist across container restarts because we’re using a Docker volume in Pihole’s service definition.