Meorawr's recent activity
-
Comment on Before you try to do something, make sure you can do nothing in ~comp
-
Comment on What have you been watching / reading this month? (Anime/Manga) in ~anime
Meorawr LinkAs I only recently joined I'll include some stuff from last month too. Kaguya-sama: Love Is War Both reading (up to ch. 232) and watching this one. Currently I'm struggling to continue reading...As I only recently joined I'll include some stuff from last month too.
Kaguya-sama: Love Is War
Both reading (up to ch. 232) and watching this one. Currently I'm struggling to continue reading this because I'm all too aware that I'm rapidly closing on the end; I've thoroughly enjoyed the entire series from start to where-I'm-currently-at and really don't want it to finish. It has however certainly earned the honor of being on my future-rereads list. In terms of the anime adaptation I'm finding it to be just as enjoyable as the source material and feel it doesn't miss any opportunities to sometimes even outshine it.
Bungo Stray Dogs Season 4
This show in general I feel just grows in strength every season and it was very hard for me to just not outright binge the entirety of the most recent season in one sitting. Very much looking forward to the continuation.
Yowamushi Pedal: Limit Break
A portion of the characters I think carry this show and allow me to overlook its numerous flaws. I do certainly fundamentally enjoy the show and will continue to do so if it gets more seasons, but I am concerned that going forward the majority of the characters I've particularly liked are ones whose relevancy is now for the most part over. I'm not sure if this is a problem with the newer characters not being as good as the outgoing ones, or if I'm just not giving them a fair enough chance.
Blue Lock
I'm writing all these sections out-of-order and this is the last one so I'll just phone it in and say "yeah it's good".
The Disastrous Life of Saiki K.
This is just a rewatch that I'm just doing passively in the background. I don't want to say it's the greatest comedy of all time but I'd be hard pressed on the fly to list anything that comes close.
Bofuri: I Have a Really Long Title That I'm Going to Omit
Generally enjoyable show that doesn't demand any effort on my part to care about or get invested in any characters or story; basically meets my needs for something that I can watch two or three episodes of on some random day in the month and then pick it up again weeks later guilt-free. Currently toward the end of the second season, but not sure when I'll watch the final block of episodes.
Edens Zero
Reading this one rather than watching - though I'll watch the adaptation at some point. I'm very early on in the series so far (ch. 32) so can't really say much other than that I enjoyed it enough so far to want to continue it.
For the the upcoming month I think the immediate plan is basically Oshi no Ko, Dr. Stone: New World, and the latest Demon Slayer season. After that we'll go back to the usual order of picking things from the list in a chaotically random manner.
-
Comment on Local DNS resolution for server? in ~comp
Meorawr Link ParentIf I'm understanding the question correctly then yes, I believe a reverse proxy is likely to be the most efficient way to meet your stated goals even for "internal" queries (which I'm assuming...If I'm understanding the question correctly then yes, I believe a reverse proxy is likely to be the most efficient way to meet your stated goals even for "internal" queries (which I'm assuming means "queries from arbitrary devices on my home network").
As it's no longer 2:30am I'll elaborate a little bit more with an example from my current setup.
My setup consists of services running directly on a single mini PC with Ubuntu 22.04 as the OS. I'm not using and have no experience at all with unRAID, and I'm not using any form of containerization software such as Docker. The avoidance of containerization in my case is entirely just down to personal preferences rather than any technical reason.
On that system is PiHole is installed and acts as both the DHCP and DNS server for my entire home network. I've added a single custom DNS record (which I'll refer to as
home.example.org) that resolves to the static IP that I've assigned to that the system.One difference between us is that I'm not using the
.localTLD but rather just a private subdomain of a domain name that I own. I'm the king of the castle when it comes to that domain, so I define what is and isn't valid :)Next up is the reverse proxy - in this case I'm using nginx. Alternatives like Caddy and Traefik exist and may compose better with containers, however I've no experience with those. The relevant part of my configuration are the two files you can find in this Gist.
The nginx server is listening on the default ports of 80 and 443 and so responds to all requests sent straight to
home.example.org. HTTP (80) simply redirects to HTTPS (443), though that's handled somewhere else in my configuration and isn't shown in the above link. For HTTPS nginx is providing TLS termination through an automatically-managed LetsEncrypt certificate obtained through a DNS-01 challenge.As I'm only using a single DNS record I've set up nginx such that access to individual services is
/pathbased; for example I'll navigate tohttps://home.example.org/jellyfinif I want to access my Jellyfin installation. Nginx then forwards these requests to the individual services which I've configured to accept standard (non-encrypted) HTTP requests and bind their ports to a local-only network interface; either the loopback (127.0.0.1) adapter or a veth interface pair for services that are cross-communicating between network namespaces (172.16.0.{1,2}). -
Comment on Local DNS resolution for server? in ~comp
Meorawr LinkYou'll need a bit more than just DNS records here. When it comes to address resolution the main record types queried from a DNS server are the A (IPv4) and AAAA (IPv6) records. These only provide...You'll need a bit more than just DNS records here.
When it comes to address resolution the main record types queried from a DNS server are the A (IPv4) and AAAA (IPv6) records. These only provide a mapping for host names to addresses; there's no way within those specific record types to additionally specify a port number.
Other record types such as SRV can include port numbering information, but within the context of accessing services via a browser those record types aren't going to be queried when accessing a website.
A solution as such is to set up a web server that listens on the default port(s) of the address that the DNS record is pointing to, and to then configure the web server to act as a reverse proxy that forwards requests through to service(s) that can be listening on any arbitrary IP and port combination.
The nature of this configuration can unfortunately be quite service-specific, as the web server may need to be additionally told to add or rewrite certain HTTP headers so that the backend application can correctly process the forwarded request.
-
Comment on Self-hosters! Share your reasons for self-hosting and favorite apps! in ~comp
Meorawr LinkMost of my self-hosted stuff is on an Intel NUC that I bought back in early 2019. That purchase was initially made so that I could have a low-power always-on Linux system on the home network for...Most of my self-hosted stuff is on an Intel NUC that I bought back in early 2019. That purchase was initially made so that I could have a low-power always-on Linux system on the home network for random odds and ends - such as running a PiHole server for the local network.
As of more recently it's graduated into acting as a media server running Jellyfin and various *Arr apps as I found myself getting very, very tired of the lack of predictable content availability on streaming services.
Overall the system is working very well and was a purchase that I've been extremely happy with. At some point I need to make some improvements to my media storage approach as the current "solution" for that is two USB disks that I had lying around in a drawer for who-knows-how-long plugged into the NUC and balanced at a file-level via mergerfs. Not the greatest setup, but it did cost me absolutely nothing to get running and was a good excuse to reuse those drives.
I've also got a bottom-tier DigitalOcean VPS for things that need to be always-online and remotely accessible in a pinch; which at the moment is just limited to a (secondary) Git and Subversion server for personal projects. Have been tempted to also set up a Wireguard server on there and peer it with the NUC to give me remote access to home resources, but I don't yet have a definite need for that.
I think this post just generally underscores the importance of trying to do things in incremental steps rather than diving head-first into a problem and getting roadblocked later on by an issue that can't trivially be extracted out and tested in isolation.
As a rather convenient example I'll take what I worked on this morning. A colleague requested a tweak that would disable the integration of our software into the system service manager based off a development-only flag that can be persisted elsewhere.
This change requires tweaks in a place that would - normally - take about 20 minutes to build and deploy. As the idea of pointless masochism doesn't spark joy in my eyes, I'd opted to break the task down into a few steps on a running test system.
After all that I was reasonably confident my proposed change would work and integrated it into the source tree proper, and shortly afterward kicked off that build/deploy cycle. The changes ultimately worked on that first deployment precisely as expected with no surprises at all.
Had I not taken the incremental approach then things would have been far more painful; there were plenty of depressingly simple mistakes I'd made throughout those steps that took seconds to fix but would have necessitated multiple redeployments.
Contrast this to a separate task that a colleague recently worked on.
The story here would be that they were to integrate support for an encrypted network link in a piece of client software of ours. They took the approach of largely just hammering this right into the software as one giant amorphous blob of a changeset that seemingly touched north of 30 files.
The colleague however during this ran into an issue that they had trouble diagnosing - seemingly, when using the encrypted link things would hang somewhere and no further exchanges of messages were occuring.
When I ended up trying to debug this issue myself and see what was going on I only very lightly looked at the changes they'd made to at least confirm some semblance of apparent correctness - and happy with that, I then promptly closed the tab and didn't look at their changes further. Even if I'd wanted to reproduce the issue with their changes, debugging the cause behind it would have been a nightmare given how deep some of these changes were cutting.
So rather than join my colleague in their little tar pit I took a step back and did things incrementally from scratch. I wrote a separate minimal test application that verified I could fundamentally open an encrypted socket to the remote target, that I could get basic authentication of peers passing, and that I was able to perform a basic ping-like message exchange through our protocol.
In contrast to the two weeks my colleague had spent on this task so far, my attempt to reproduce the issue with a minimal clean test case took about three hours to write from scratch and led to an identification on the issue - there was a bug on the other end of the socket where it got stuck waiting for data that'd never arrive. Ultimately I was able to have a fix in-place ready for testing about an hour after and deployed internally end of the day.
What benefitted me the most was that I was able to isolate precisely at which step things were going wrong, and could make further changes around that one area to confirm or deny various theories on the underlying cause. Doing this in the context of the full changes my colleague had tried applying to the client software probably wouldn't have been impossible, but it would have taken considerably longer.