There is a thread in every selfhosted community every few weeks about keeping documentation together, and the top answer is usually a joke about not having any. That is what this is for.

Homedex connects to your Docker hosts, plain SSH hosts, and Traefik, Caddy or Nginx Proxy Manager, then keeps a record of what is running where, on which port, behind which route, and when the certificates expire. It also keeps a change feed of what actually moved since the last scan, and flags routes pointing at containers that no longer exist.

The part I could not find anywhere else: it parses reverse proxy config and joins it against discovered containers, so you get the domain to container mapping. That is the one nobody remembers and nobody writes down.

Why not the usual suggestions. NetBox is good but it is a source of truth you type into, and for a homelab it becomes a chore. This has zero data entry. Scanopy draws topology maps, which is a different question to keeping records. Portracker does ports only, no routes or certificates.

One Go binary with the UI embedded, or a distroless container around 12MB for amd64, arm64 and armv7. SQLite on disk, no telemetry, works fully air-gapped. Read-only by design: there are no write paths to the Docker API at all, the bundled compose file reaches the socket only through a filtering proxy with POST disabled, and container environment variables are never ingested so credentials cannot end up in an export. There is a CI check enforcing that last one.

MIT, self-hostable in full with no paid tier. A month and a half old, one contributor, green CI and tagged releases. I run it against my own stack but I am not claiming maturity.

AI declaration

• Design (architecture, system design): Pair
• Implementation (production code): Generated
• Testing (tests, test plans, QA): Generated
• Documentation (docs, comments, README): Generated
• Review (code review, PR feedback): Assisted
• Deployment (CI/CD configuration): Generated

I set the data model, the connector interface and the security posture, and reviewed and reworked throughout, but most of the code itself was generated under that direction.

One concrete example of what that costs, since it is more useful than a label: containers were originally keyed by their Docker container ID, so a redeploy issued a new ID and the tool silently orphaned any notes attached to a service and reset its first-seen date. Fixed in v0.1.4 by keying on the container name. The compose service name does not work either, because scaling gives three live containers the same one.

I'll copy the whole announcement here for those who don't want to click:

I regret to inform everyone that my copy of QBittorrent escaped its sandbox last night and downloaded a whole bunch of content owned by major corporations, and then my copy of Jellyfin broke containment and added those unfortunately-downloaded media files to its various libraries. I'm conducting an internal investigation to figure out how this happened, which will involve consuming these media files until the answers become apparent. Thank you for your cooperation during this trying time.

Having fought for several days with this, I'd thought it would be worth sharing while it's still fresh in what's left of my mind:

Problem:

• OpenWRT router running latest available version (25.12) and Luci UI.
• IP cam that I want hardwired-only (Ethernet).
• Cam must have no access to internet or rest of LAN.
• Cam must only be accessed directly by the NVR software.
• Software (NVR and reverse proxy) run as docker containers on server PC.
• Any other LAN device (laptop, phone) must be able to access the NVR only via the reverse proxy.

Network topology:

• Cam is plugged physically in lan1 port on router.
• Server is plugged physically in lan3 port on router.
• The problem above basically means we need two tagged VLANs, one for regular LAN devices, and one just for NVR and camera.

Configuring the VLANs in OpenWRT:

Before anything else: try doing the next batch of configs from wireless if possible not Ethernet, in case you mess up and lose wired connectivity to the router.

• Go to Network > Interfaces > Devices and press "Configure" for the bridge that holds your router ports. This will typically be called "br-lan".
• Go to the "Bridge VLAN filtering" tab and check "enable Vlan filtering".
• Press the "Add" button twice to get two VLANs.
• First VLAN: set id=1, check "local", mark lan1=off (not member), lan2=untagged, lan3=tagged (also primary), lan4=untagged. You can use any ID but "1" is traditional for the base LAN network.
• Second VLAN: set id=100, check "local", mark lan1=untagged, lan2=off, lan3=tagged, lan4=off. Again, you can use any ID, but it's traditional to avoid numbers under 10 because they're typically used for core VLANs.
• Case in point, please note that my router has two physical NICs, one for LAN ports 1-4 and one for WAN, so I have a separate br-wan device just for wan. But some routers only have one physical NIC so they only have one bridge that covers both lan1-4 and wan ports. On these routers when you get to the filtering tab you will find two VLANs (1 and 2, typically) already set up. If this is the case add the VLAN 100 and modify VLAN 1 as above and mark wan as off in 100.
• After you press "save" you will notice two new virtual devices called "br-lan.1" and "br-lan.100" type VLAN 802.1q have appeared in the device list.
• Do not apply modifications yet. First go to Network > Interfaces, edit the "lan" interface and switch it from device "br-lan" to device "br-lan.1", otherwise you may lose connectivity to router if you're on Ethernet.
• If you've applied changes early and lose connectivity, don't panic, just wait. In recent OpenWRT versions after 90s without confirmation from the UI the router will automatically rollback the last changes.

If all went well and you're on wireless or one of the untagged Ethernet ports (lan2 or lan4) you should have retained connectivity to the router and wireless devices.

Configuring the NVR network in OpenWRT:

• Go to Network > Interfaces, click "Add new interface".
• Call it "NVR", protocol "static address", device "br-lan.100".
• Next, edit it and set up your desired IPv4 address and netmask.
• You MUST go to "firewall settings" and use the "custom" field to add a new "NVR" zone. alternatively you can go to Network > Fireall, create the NVR zone there, and choose it here.
• Enable DHCP if you want.
• If you do, please note that some routers bind dnsmasq only explicitly to select interfaces. Please check under Network > DHCP > dnsmasq > Devices & Ports and if "non-wildcard" is checked you will have to add "NVR" to the "Listen interfaces" to actually get DHCP services on that network.
• Under Network > Firewall you should have a zone called "NVR". Set input/output/forward to accept/accept/reject.
• Under Network > Firewall > Traffic rules you have to add a new rule, calld it "NVR DHCP", that says that protocol UDP, source zone "NVR", destination "device (input)", destination port 67, action "accept", and under advanced restrict address family to IPv4. Traffic rules have priority over zone configuration so DHCP will work no matter how you fuck up your zone access.
• We will be skipping DNS because we don't want the NVR network to benefit from any. But if we did we'd be doing the same we did for DHCP (got to Network > DNS to enable explicitly on NVR interface, and add a traffic rule for it).

Configuring the camera:

• Plug the camera into port lan1, it should pick up a DHCP address on the network you've defined for interface "NVR".
• In order to be able to access that IP from your regular LAN to configure the camera with your phone you'll have to temporarily add the "NVR" zone to the list of forward zonez of the "lan" zone.
• Would probably be a good idea to either configure the camera to a static IP or give it a static DHCP assignment based on the Ethernet MAC, so you know where to reach it from the NVR software.
• Remember to remove the "NVR" zone from the lan's zone forwards when you're done.

Configuring the server for tagged VLAN connectivity:

• Your server (port lan3) was marked for tagged VLAN connectivity in OpenWRT but it doesn't (yet) actually use tagged connections. We have to fix that or it won't be reachable.
• Feel free to mark lan3 as "untagged" on VLAN 1 to connect to it while you change the settings, but keep in mind that direct console access may be needed if you fuck up.
• My server runs Debian so configuration basically runs down to loading module 8021q (and adding it to /etc/modules just in case, although this should be largely automated), and editing /etc/network/interfaces. Feel free to adjust the example below to your needs:

# this will bring up eth0 but leave it unconfigured, merely as a support carrier for the VLANs 
auto eth0
iface eth0 inet manual

# this will set up VLAN ID 1 and tell it to use DHCP
auto eth0.1
iface eth0.1 inet dhcp

# this will set up VLAN ID 100 with a static address
auto eth0.100
iface eth0.100 inet static
	address 10.234.100.2/24

Configuring docker networks and containers:

• Remember I said the proxy and the NVR are running in docker containers. If you haven't done anything fancy with them before, you were probably using ports: to expose a port for the proxy and one for the NVR on the host's LAN IP, and pointing the proxy to the NVR.
• First, we will want to make an ipvlan or macvlan docker network that will use the eth0.100 interface. Containers that use this network will be placed in the NVR network/zone, and have their communications tagged with VLAN ID 100. Feel free to customize the network range. You can use either ipvlan or macvlan, the latter is not very useful since docker can't do DHCP. Note the use of aux-address to reserve the IP you've assigned the camera, in case there's potential overlap with the range you choose for automatic allocation. It's essential that you use the eth0.100 interface as parent.

docker network create --driver ipvlan \
--ip-range=10.234.100.97/27 --subnet=10.234.100.0/24 --gateway=10.234.100.1 \
--aux-address 'cam1=10.234.100.10' \
-o parent=eth0.100 nvr-vlan

• We also need a bridge network that will allow the proxy to see the NVR container, because once the NVR container is placed on the NVR network on the VLAN ID 100 it won't be reachable directly by the proxy.

docker network create --driver bridge \
--opt com.docker.network.bridge.name=br-docker-proxy \
--ipv4 --subnet=172.23.1.0/24 --gateway=172.23.1.1 \
proxy-bridge

• Next, in the NVR container compose, join both proxy-bridge and nvr-lan:

services:
  nvr:
    networks:
      nvr-vlan:
      proxy-bridge:
    hostname: nvr
networks:
  nvr-vlan:
    external: true
  proxy-bridge:
    external: true

• Also in the proxy container compose you will want to join the proxy-bridge network.
• Remove the ports: directive from the NVR container, it doesn't serve any purpose now. Containers on ipvlan/macvlan are reachable by their native port assignments on the networks they've joined.
• Please note the hostname: nvr in the NVR compose, that's the name you will have to use in the proxy configuration to reach the NVR. Docker will supply a DNS resolve for this automatically.
• The proxy doesn't need to be on nvr-vlan. I mean you can, but you need to keep the proxy accessible from the main network so it will keep using ports: as usual.

Bibliography:

• https://docs.docker.com/engine/network/drivers/ipvlan/#manually-create-8021q-links
• https://openwrt.org/docs/guide-user/network/vlan/switch_configuration
• https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa
• https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial
• https://forum.openwrt.org/t/openwrt-vlan-tagging/208098
• https://computingforgeeks.com/how-to-configure-vlan-interface-on-debian/
• https://wiki.debian.org/NetworkConfiguration#Howto_use_vlan
• https://manpages.debian.org/trixie/ifupdown-ng-compat/interfaces.5.en.html
• https://deepwiki.com/openwrt/firewall4/6.1-zone-configuration
• https://deepwiki.com/openwrt/firewall4/7-rules-and-nat

Self cross-posting from: https://lemmy.zip/post/70909658

Intention to have slightly better visibility from the self-hosted crowd and I'm interested in more general feedback on this too.

Hey everyone! I'm trying to find a solution to a really confusing problem...

I have the following simple nginx docker compose configuration on my Fedora home server that I can run without issue on my uid 1000 user, lets call this user "userA".

services:
  nginx:
    container_name: nginx-alt
    image: docker.io/library/nginx
    restart: unless-stopped
    ports:
      - 8181:80

This exposes internal port 80 as 8181 and can be accessed in a lan in the expected matter.

However, for security reasons, I want to actually host this service eventually on a completely different user with less permissions. Let's call this user "userB" who has a very limited scope of the file system. This is to prevent potential escaping of the rootless container causing major file system havoc (i.e. reduce the scope of the user to a very limited network of containers.)

The problem is really simple: For some reason, when userB runs this service (uid 1001), the nginx service suddenly complains about privileges. As a result, I get a "Forbidden 403" error when hosting. Turning off selinux has no affect (so setenforce 0 does nothing, meaning I can rule out secure linux interruption.)

The errors look like the following:

nginx-alt  | 2026/09/04 20:03:34 [error] 25#25: *1 "/usr/share/nginx/html/index.html" is forbidden (13: Permission denied), client: xx.xx.x.x, server: localhost, request: "GET / HTTP/1.1", host: "xxx.xxx.xxx.xxx:8181"
nginx-alt  | 10.89.0.2 - - [04/Sep/2026:20:03:34 +0000] "GET / HTTP/1.1" 403 153 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:155.0) Gecko/20100101 Firefox/155.0" "-"

For what it's worth, both users should be relatively vanilla and all ports are appropriately exported. There shouldn't be anything, for example, that is making userA run as "privileged" over the other users and podman should be running rootless in both containers.

I did see a note on the nginx image about running in rootless that I might try, but it doesn't solve my bigger issue here which is the lack of consistency between the two users. Additionally, userns_mode: keep-ids only caused the container to fail to boot for other reason entirely.

There must be something fundamentally wrong with my configuration of my system. Has anyone had any experience running two podman containers on two different users simultaneously that can provide feedback?

Obviously, I'm not trying to run just an nginx server, but I found this to be the easiest configuration to reproduce.

I'll just provide my own example: my homelab consists of 6 Kubernetes nodes placed across the country. Some differ by ISP, some are placed in different cities, one is hosted on a cloud provider. Basically it's a very cheap variant of geo-replicating my workloads.

Two of these nodes are visible from the Internet and have a static IP address; one node also has an IPv6 address. Each node hosts an authoritative DNS server (CoreDNS) for my personal domain pootis.network; and the .network TLD has glue records which point to IPs of these two nodes. This is a classic "self-hosted DNS" scenario.

Here's an excerpt from my zonefile so you can understand the setup better:

$ORIGIN pootis.network.
$TTL 300

@       SOA     ns1.pootis.network. admin.pootis.network. (
  2026082001
  1200
  300
  1209600
  300
)

; Nameservers and glue records
@       NS      ns1.pootis.network.
@       NS      ns2.pootis.network.
ns1     A       178.44.116.85
ns2     A       91.219.150.30
ns2     AAAA    2a06:dd00:1:4::4189

This 5-record block (NS/A/AAAA) is mirrored into the .network zone by my domain registrar (plus DS for DNSSEC but that's another thing).

As such, my DNS becomes fully independent - and, in theory, if one of my externally-facing nodes breaks, let's say ns1, then DNS resolvers all over the world (forwarders, recursive, and such) will fall back to ns2, and everything will keep working. Kubernetes will also reorganize the pod placement so all my workloads are available again after a slight downtime.

That would have been great, if it worked as described, but apparently, after one nameserver in my zone fails, then the resolvers... just give up? Let's say ns1 failed but ns2 is working. The parent zone still points to both nameservers. My external resource records (websites and other stuff) at this point would have already been auto-reconfigured by a custom k8s controller to point to the IP addresses of the node that hosts ns2. Simplifying: the entire world basically sees this after ns1 fails and after TTL caches expire:

; all of this has very low TTL, 5 minutes or so

@       NS      ns1.pootis.network. ; from .network 
@       NS      ns2.pootis.network. ; from .network

ns1     A       178.44.116.85 ; broken. Either from .network glue or from my auth DNS
ns2     A       91.219.150.30 ; either from .network glue or from my auth DNS
ns2     AAAA    2a06:dd00:1:4::4189 ; same

; my-website     A       178.44.116.85 ; does not appear because ns1 is broken- my LB already removed it from the set
my-website     A       91.219.150.30 ; fronted by a pair of CNAMEs due to loadbalancing but still
my-website     AAAA    2a06:dd00:1:4::4189 ; same

But even if I query 1.1.1.1 directly for my-website's record, it just doesn't work most of the time because the resolver pins itself to ns1 which is currently failing, or it selects ns1 and does not even care to try ns2.

To be precise: some resolver implementations DO fall back to ns2 as expected, but most of them just pin themselves to ns1 and then outright refuse to resolve the records in my zone.

And there's actually no reasonable way out, as far as I can see:

• moving my DNS infra somewhere else (CloudFlare, for example) is unacceptable since I would like for my homelab to be as independent as practically possible;
• anycasting, or running a fully-fledged BGP AS is also impossible because that costs a lot of money and I'd like for my homelab to fit into a $10/month budget with room to spare;
• "live-patching" the NS and glue records in the parent zone (.network), to keep up with the set of my working nodes, is possible, but very unwieldy and somewhat hard to accomplish.

There's a lot of custom machinery that keeps my workloads running and accessible after a node failure, but all of this becomes completely moot when authoritative DNS is the bottleneck.

Has anyone been running a similar stack and encountered this problem? I'm aware that the answer is usually "host your DNS at CloudFlare" or "use the registrar's DNS infra" but still...

cross-posted from: https://discuss.tchncs.de/post/66988984

What I have

I have an old Acer Aspire A515-51G and I also have a desire to have a home server. In combination this creates a need for the laptop to carry more HDDs than it can from factory. Usually it can take one M.2 SSD and one 2.5" SATA drive.

What I want

I want to make the laptop able to run at least 4 HDDs in RAID 5 for storage and have one SSD as boot drive.

What I did

The buying phase

• 4 HDDs
• M.2 to SATA adapter
• 12V/5V SATA power converter
• 12V 10A power supply

The designing phase

I needed space to hold the HDDs, so I designed a 3D printed a cage to attach to the bottom of my laptop. Two 80mm fans can be attach to it. You can see it on printables. Also I remixed a tray (here is the original) so the HDDs can slide in and out of the cage.

.

The assembly phase

A cutout at the bottom of the laptop was needed to give access to the SATA ports of the adapter.

I put a 2.5" SSD into the already present place for it in the laptop.

Then the cage was attached to the laptop, the HDDs were put in their trays, the trays inside the cage and the cables attached to the adapter and HDDs.

Hi there my dear people of r/selfhosted! Fresh bunch of Dawarich news is due, make yourself comfortable :) To whom it may concern, Dawarich — is your (is and always will be) a free open source self-hostable alternative to Google Timeline.

AI Disclosure (as per https://lemmy.world/post/49320548):

Implementation - Generated

Testing - Generated

Design - Generated

---

Our links:

Github: https://github.com/Freika/dawarich

Website: https://dawarich.app/

iOS app: https://apps.apple.com/us/app/dawarich/id6739544999

Android app: https://play.google.com/store/apps/details?id=app.dawarich.Dawarich

---

Nine releases, what a month! And not a puny ones, this time we managed to speedrocket Dawarich performance in browser. If you have hundreds of thousands (or even millions!) of points and you'd love to see them all on the map, previously that would be not an easy task for Dawarich. It would crash your browser, as many times as you try loading the data. But no more! Our very own community member, the man behind the Docker image we're using to run Photon, Robin (https://github.com/rtuszik) suggested a fresh approach to loading points: just render them as map tiles! Together we brought this idea to life and now my own dataset consisting of 957,350 geo points gets loaded in less than 1 second! That's kinda insane to me, to be honest. And yeah, instead of ~590MB of JSON transferred to your browser, it took uhhh 150KB? Just don't forget to enable the toggle in the map settings.

---

If you want to drag your points, do disable it though, seamless points editing will be added bit later. Oh, and tracks are being now served in the same manner, too. And routes, and fog of war layers. It's all a lot faster now! Dawarich now speaks 6 languages! German, Spanish, French, Polish and Catalan were added to the default English. Simplified Chinese is on the way, and feel free to suggest your own locales :) You can change it in Settings -> General

---

Visit detection was rebuilt from scratch and it's finally useful. God knows I procrastinated this feature long enough, but now it's in a very good shape. Suggests real places I visited, and community members are also confirming it's not just me — for them it also yielded very relevant results. By the way, you'll no longer see the annoying "99+" counter of the visits on your timeline button. We all hated the feeling of an unfinished job but let's be real ain't nobody got time to click all the suggested visits. Now they are just there, without the irritating counter, sitting patiently, waiting for you to delete them or... just let them be. They are precise enough now, after all, so why not, right?

Deleting a visit also leaves an invisible tombstone now, so the visit won't be resuggested again. And the Timeline panel got much cleaner. I'm still not entirely satisfied with its state, so some changes are due, I want smoother UX.

By the way, one of former Dawarich user mentioned something like we're making the Timeline "less and less useful with each release", so here I'd like to use the opportunity and ask you guys, do you share same feeling? What's good about Timeline, what's not so good? I'd love it to be as useful and convenient as possible, so your feedback is very important. Thank you!

Transportation modes, also rebuilt. This one is a lot trickier and even Google itself fails to properly attribute the way a human being moved (suggesting driving over train ride for example), but it's still got significantly more reliable. I have some cool work ahead of me to make it even better, but that's a secret.

---

Videos are finally here! God I love videos. The Video Studio first was released as a free tool on our website (https://dawarich.app/tools/route-video-maker/), and then I added it to Dawarich itself, which makes it easier to use your own routes to create a video.

Check it out!

And here's an actual video produced by Dawarich Video Studio: https://youtube.com/shorts/mEUe4RktKSg

Also, the "Share" button on the map page now also has a way for you to create and share a poster or a video. Your memories were never more material!

Rendering is being done in your browser, and it allowed me to not cram another backend service into the Dawarich stack, neat.

---

Map v1 (Leaflet) is gone. I'm surprised nobody really complained about it. I'll take it as a sign that Maplibre version is a lot better!

---

Geocoding settings are now available in Settings->Integrations, with selection of providers supported by Dawarich and appropriate settings available for them. The ENV vars are still there and take precedence over what's configured in the UI, so no breaking changes.

---

Imports got smarter:

• Google Takeout & Polarsteps now extract visits, named places, tracks and the source app's tication — not just raw GPS points. Google's own place names (Home, Work…) are kept. Older imports: "Extract additional data" in the Imports list. "Remove extracted data" undoes it without touching your points.
• FIT files with developer data fields (Wahoo devices) now import instead of failing to parse
• Traccar KML exports now import LineString points instead of finishing with zero.
• Google Timeline: fixed altitude/accuracy/speed being silently dropped from rawSignals, and estamps no longer scramble path order.
• Imports finishing with zero saved points now tell you instead of completing silently.
• Tracks no longer stitch two different devices together (Records.json contains every device

---

Tracks calculation got a lot smarter: fewer skims along the route, better anomaly points detection, better distinction between different devices tracking simultaneously, hence stats distance calculation now has better precision.

---

Preparation work is being done for the Family feature coming to our mobile apps. We're currently testing it internally and are hoping to release it there soon. Also, OwnTracks' HTTP mode now can show your family members in the app: every upload is answered witveryone sharing with you.

---

Database optimisation works are also in progress: most of the August releases are containing some changes to how Dawarich writes and serves your data, it may lead to bigger space consumption. In the end, when the process is done (hopefully before end of September), I'll provide an instruction on how to shrink your databases with no data loss. If you'd like to do it now — do the full vacuum to the points table. For the rest of you — please wait for the next post or keep an eye on our changelogs, it will be there.

⚠️ If you're upgrading from 1.10.x, do these once

• Restart the app after migrations have run — until then, deleting a visit looks like it worked without saving.
• Settings -> Visits -> re-detect (self-hosted does this fleet-wide automatically; SKIP_VISITS_FLEET_REDETECT=1 to opt out).
• Map settings -> Transportation Mode Detection → "Re-classify my history."
• Map v2 -> Settings -> "Recalculate tracks & stats" to apply the gap-distance fix to past months.
• Expect background backfills to run for a while on big histories. Progress is under Background jobs settings.

---

Mobile app UI was updated! It now includes better navigation between days, you can select date range to show your data, and you can also replay your day on the map. We added new layers: points and heatmap, more to follow.

If you're hosting Dawarich behind cloudflared or similar gateway, you can now benefit from custom HTTP headers to connect your mobile app to your Dawarich instance.

We added Smart Tracking mode for Android and Continuous Tracking mode for iOS. Enable precise tracking mode to see the toggle. Both modes use motion-aware updates to toggle tracking on and off to save your battery life.

---

Well, I guess, that's it for today?

And as always, our links one more time to save you a scroll:

Github: https://github.com/Freika/dawarich

Website: https://dawarich.app/

iOS app: https://apps.apple.com/us/app/dawarich/id6739544999

Android app: https://play.google.com/store/apps/details?id=app.dawarich.Dawarich

Donate: https://www.patreon.com/freika / https://github.com/sponsors/Freika/

---

P.S. 1st of October I'll be speaking at Berlin's Geomob event ( https://thegeomob.com/ ) come and say hi!

See y'all soon!

cross-posted from: https://discuss.online/post/44941820

All services have been migrated, now including the podcast. It was stressful, because Castopod has zero such documentation. I started with Dokuwiki (files and folders), then worked my way through migrating Flarum from MySQL to MariaDB. Spun up some new services via PostgreSQL and SQlite. Flarum at least gave me the experience of gaining some foundational understanding needed to then migrate Castopod via mysqldump, adjusting permissions, rewriting .htaccess to redirect to a simple migration.html page and eventually flip DNS after carefully adjust cron and tasks:list expected by php spark for Castopod.

Because it is always federating, with no supported method of disabling, I was terrified of it breaking. Obviously, it still could... but, it seems to be working.

Hello self-hosters! :) I'd like to tap into your experience

tl;dr: Is it really a bad idea to use MariaDB with data over NFS?

My setup

• RAID NFS NAS on RPi4
• "CPU machine", just an old laptop for now

The idea is that NAS stores the data and RAID mitigates single point of failure. Laptop is only for running the stuff, all docker-compose are under git, uploaded elswhere. Laptop fails - I buy a new refurbished one and put everything back together from data on NAS and git

Problem

But Nextcloud uses DB. ATM it sits on the laptop. And I'm thinking how to somehow move that data to the NAS.

At the beginning NAS was just for NC files, connected as NC "external storage" over SFTP. But there were issues with this setup and NFS4 turned out to not require Kerberos to work.
Since NFS docker volumes have been working quite fine, I thought about just moving the data to the NAS. But then I read this:

Generally, we recommend not to use NFS (Network File System) with MariaDB, for these reasons:

• MariaDB data and log files on NFS volumes can become locked and unavailable for use. Locking issues may occur in cases where multiple instances of MariaDB access the same data directory, or when MariaDB is shut down improperly, for instance, due to a power outage. In particular, sharing a data directory among MariaDB instances is not recommended.

• Data inconsistencies due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.

And I feel discouraged

• I could move whole DB (I mean including the process) to the NAS, but then operating the DB becomes NAS' burden and breaks the responsibility separation
  I'm not a fan of this idea
• I could treat NAS as first stage of backup for that DB data and just send the data to NAS once a day
  Also a bit meh. Getting back up from server failure will require copying the data
• Maybe it's not that bad to use MariaDB with NFS?
  If there is a problem with server-NAS connection, I actually don't want Nextcloud to work at all. It should fail, so I know I need to fix something

So, what are your experiences? Is running the DB on one machine, using the data from another machine over NFS a shot in the foot?

First and foremost, I’d prefer to be honest about my use of AI:

Testing – writing tests, test plans and QA: Pair

That’s it! I think my commit history will speak for itself.

I've been a member of this community for a very long time now (ever since the Reddit API crisis and my move to Lemmy) and for several years now, I’ve been thinking about sharing my personal project with you. There is a good reason why I’ve hesitated for so long : I’m happy with what I’ve done, but I haven’t been a professional developer for a long time, and it shows in my UI :D

But nothing ventured, nothing gained, and that’s why I’m taking the plunge today to introduce you to a timeline management tool.

It’s simple, still a bit rough around the edges in some respects (particularly the table-based editing mode), and you’ll certainly find some features missing, but it does the job for me at the moment.

I’m sharing this with you today for two reasons:

• To showcase my work, and perhaps give you a pleasant surprise
• To get your feedback on what you see, and any missing features that might make you want to use it

Because if I’m going to spend my evenings working on a project like this for several years, it might as well be of use.

Here are a few ideas for features I’m currently thinking about :

• Implementing other types of charts (like gantt)
• New options to customize color
• Zooming in/out on your charts
• Implement the option to enable authentication on your instance
• Implement the option to enable the organisational principle for grouping and sharing creations by different users

The product can be tested online completely free of charge or tested using its Docker image

Thank you in advance for taking the time to consider my project. I look forward to hearing from you soon.

Oracle recently changed their free VPS allowances, taking down my Nextcloud instance. I'm moving my file sync to a local machine but was wondering if anyone had any experience with alternatives, as Nextcloud AIO was a major pain in the ass to set up last time.

I used it for sharing WIP music projects so having a web interface where I can listen to audio files from a browser was really convenient. It seems however, that all apps offering this feature are just as heavy as NC.

I tried installing cloudreve, but the web media player seems borked on firefox.

Does anyone know any good alternatives, preferably ones which can run off a single docker compose file?

I have a BRAVIA 4K AE1 android/google TV.

Since a few weeks I observe the following:

If it's disconnected from the internet for some time, 1 or 2 weeks maybe, it hides all my installed apps. Enabling internet immediately restores everything for a few days.

I tried installing a custom launcher and set it as default launcher - TV still boots into its system launcher.

Any ideas what else to try?

Self hosting relevant because jellyfin

Edit Fixed by enabling accessibility for this app. Thanks everyone who helped and @ryannathans@aussie.zone for pointing this out.

I think a couple of months ago I found out about Dawarich here on this community as the author posted here. I installed a couple of days ago on a VM I run and have been impressed so far. I started logging track 10 years ago when I found out about OsmAND and never really knew what I would do with those tracks until I discovered Dawarich. Interesting piece of software. With the "trips" function, it reminded me of my trip to Scotland and all the places I had seen on which day.

Now the challenge is to understand why Owntracks feeds it a couple of points a day and only when I'm at home. I thought Owntracks would log locally on mobile phone and then download everything on Dawarich when it was back online on the VLAN at home (i don't have external access setup and don't want to for now). Is this some server side problem or a app problem? I've not changed the default settings of either the Dawarich server or the app. Any clues? I was goign to try the Dawarich android app but its not on f-droid so will need to wait until it is (strictly on GOS and no Google where I live ;-)

cross-posted from: https://discuss.online/post/44873486

I'm continuing to use an original Pi Zero and Pi Zero W, for breadboard experiments.

CookTrace is a self-hosted alternative to Mealie / Tandoor / Paprika: recipes, pantry inventory, shopping lists, and a cook diary in one app. AGPL-3.0, single Docker container, native Android app.

Part of the TraceApps family: NutriTrace (nutrition), CookTrace (recipes / pantry / shopping), LiftTrace (strength / lifting).

What v1.2.0 adds

• Ingredient links on recipe steps. Link specific ingredients to the step that uses them, and Cook Mode shows each step's linked ingredients inline with their quantities, no more scrolling back up to check how much flour a step needs. Tapping one checks it off the main list too, and finishing a step checks off everything linked to it. Tandoor imports carry this linkage over automatically.
• Wide-screen desktop layouts across six main pages plus Cookbooks. Settings, Manage, Shopping, Diary, Pantry, and Recipes all get real desktop treatments instead of a stretched-out phone layout: masonry shopping lists, a two-pane Settings shell, denser pantry and diary grids, and wider content caps on ultrawide monitors.
• Cookbooks get search, drag-and-drop reorder, and a cover image. Pick a recipe card up from anywhere on it to reorder, not just a tiny handle. Cookbook cards now show the same info as the main Recipes grid (category, rating, tags, pantry match).
• Kitchen auto-share was silently dropping recipes created on the Android app. Recipes made on your phone weren't fanning out to other Kitchen members. Fixed, and toggling auto-share off then back on backfills anything missed.
• Mobile ingredient-name suggestions no longer cover the keyboard. The field used the browser's native suggestion picker, which some mobile WebViews render as a full-screen overlay fighting the keyboard for space. Replaced with an in-app dropdown that sizes itself to whatever room is actually free.
• A batch of smaller fixes: CSRF errors on file/URL import dialogs, email links rendering as http:// behind a reverse proxy, single-user-mode data getting stranded on upgrade, pantry items disappearing when sorted A-Z with an orphaned category, and more in the full changelog.

Community contributions this release: @clifmo (email-link proxy fix), @xiaojwus (pantry sort bug report).

Security

fast-uri, browserslist, @xmldom/xmldom, and qs bumped, closing 8 advisories (4 high, 4 moderate: host confusion / SSRF via URL normalization, unbounded memory growth, XML fragment injection, denial of service). No app behavior changes.

Links

• Repo: https://github.com/TraceApps/cooktrace
• Docs: https://traceapps.github.io/docs/
• Full release notes + signed APK: https://github.com/TraceApps/cooktrace/releases/tag/v1.2.0
• Docker image (multi-arch, amd64 + arm64, Pi 4/5 works out of the box). Published to two registries with identical tag sets:
  • GHCR (primary): ghcr.io/traceapps/cooktrace:latest
  • Docker Hub (mirror): traceapps/cooktrace:latest

docker compose pull && docker compose up -d

AI Disclosure

Per Rule 7 / [AIP] disclosure requirements AI was used during development as a coding assistant. Level per category:

• Design (architecture, system design): Hint, I make the architectural calls; AI suggests trade-offs and edge cases I might have missed.
• Implementation (production code): Pair, roughly 50/50. AI drafts, I review, adjust, test on real hardware, and only commit what I've verified. Every commit is manually reviewed before it goes to my dev repo.
• Testing (writing tests, test plans, QA): Assisted, real-device testing is manual (I test on my own PC and mobile devices before every release). AI helps draft test plans and think through edge cases.
• Documentation (docs, comments, README, CHANGELOG): Pair, release notes and changelog entries are drafted with AI then edited for tone; comments and code docs are mostly Pair as well.
• Review (code review, PR feedback): Assisted, I'm the reviewer; AI helps with security sweeps, audit passes on complex changes, and consistency checks.
• Deployment (CI/CD config): Hint, Docker/GitHub Actions/release pipeline is largely conventional; AI-suggested improvements only.

---

title: "Internet centralization and the original sin of NAT" url: "https://dreamstation.systems/personal/ntppost.html"

---

File Transfer, Randall Munroe, https://xkcd.com/949, Creative Commons Attribution-NonCommercial 2.5

In this comic, the concept of an ordinary person having an FTP server is quickly dismissed. And yes, it’s not common. To the average computer user, the idea that someone could just… connect to your computer feels exotic, or even dangerous — see the very common ironic fear of your IP address being known to other people on the internet.

If you take someone who’s “good with computers” but not a networking person, their mental model of The Internet probably involves a definition of “servers” or “the cloud” that distinguishes them from personal computers in some meaningful way. True peer‐to‐peer, if they ever think about it, is an endeavor: WebRTC, STUN, TURN, ICE, what have you. Given that we live in a world of NAT, CGNAT, and restrictive ISPs, this isn’t entirely wrong, but it breaks the elegant design of the original Internet.

Why you don’t have an FTP server

Network address translation (NAT) was first formally proposed in RFC 1631 in 1994. In its abstract, it says:

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long‐term and short‐term solutions to these problems are being developed. The short‐term solution is CIDR (Classless InterDomain Routing). The long‐term solutions consist of various proposals for new internet protocols with larger addresses.

Classless interdomain routing is not the point of this post, but basically we started giving people more options for network sizes, and while complex in implementation, it was philosophically virtually uncontroversial.

RFC 1631 proposed a second short‐term solution to IP address depletion and scaling in routing: NAT. While it is not exactly the same type of NAT omnipresent on home routers today, the basic idea is the same: it allows multiple devices to share an IP address (from the perspective of a device on the other end of a routing device) by modifying the network address information in the IP packet headers while transferring the packet across a traffic routing device. We then later reserved certain addresses for private use, and these things are used in conjunction on most IP networks — private addresses within the network, NATing to one public address at the router. On your typical home router, here’s how you usually connect to an external server with NAT 1:

1. Your computer sends a packet like this:

   | Source IP | 10.11.70.21 | | Source Port | 50413 | | Destination IP | 67.215.249.229 | | Destination Port | 70 |

2. It hits your router, and it modifies it to this:

   | Source IP | 146.7.15.85 | | Source Port | 60612 | | Destination IP | 67.215.249.229 | | Destination Port | 70 |

3. The server replies:

   | Destination IP | 146.7.15.85 | | Destination Port | 60612 |

4. Your router rewrites it back:

   | Destination IP | 10.11.70.21 | | Destination Port | 50413 |

If you’ve thought this through, you might be asking: in the situation that an external server wants to talk to you first, how does that happen? It sends a packet to 146.7.15.85, and your router…

Oh no. It has no idea where to send it.

Working around it

Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time. So a whole ecosystem of workarounds grew up around NAT, none of which restore the fundamental intention of the internet, and none of which work for everything.

Port forwarding

The most direct fix is to just tell your router “hey, when a packet comes in on port 60612, send it to 10.11.70.21 on port 50413, no questions asked.” This is port forwarding, and it’s the workaround to NAT that the most people are aware of. One of the problems with port forwarding, conceptually, is that one public IP+port can still only map to one device at a time, which means that two devices can’t operate a service on the same public IP+port at the same time. This is more of a problem than it sounds like; on big enterprise or university networks that choke down to a small number or even just one private IP, this basically kills on‐prem hosting without doing even more complicated shit. And sometimes, your ISP has put your external IP behind NAT too — which is called carrier‐grade NAT (CGNAT) — and now you don’t control the device doing the translation, so you can’t forward a port. You’re getting a fraction of a fraction of an IP address.

Also, another problem with NAT is that nobody wants to bother with it, which is why we invented:

UPnP

UPnP, and its modern cousins NAT‐PMP and PCP, tried to solve the “nobody wants to bother with it” problem by letting software ask the router directly to forward ports. Like manual port forwarding, it’s a request to your router — if your ISP is screwing with you, you’re out of luck. It’s also frequently disabled because of misguided security thinking — partially because of a couple buggy early implementations, and partially because the idea that someone could just connect to your computer feels exotic or even dangerous to a lot of people. There are plenty of valid reasons to want a firewall, but if you do, intentionally implement one instead of relying on NAT just not knowing where to send packets.

STUN, TURN, and ICE

STUN

Session Traversal Utilities for NAT (STUN), instead of trying to get cooperation from the firewall, simply asks a server on the public internet “what does my packet look like by the time it gets to you?” The STUN server hands back the public IP and port your NAT assigned, say, 146.7.15.85:60612. Under a “cone NAT”, where the router uses an identical external port mapping for all outbound connections, this works great. You can tell this mapping to a peer, and then they can send packets directly to you. This technique is known as hole punching. However, under a “symmetric NAT” — common on CGNAT and institutional networks — you get a different public port for every distinct destination. In this case, the STUN mapping is useless for connecting to a peer, since they'll see you differently than the STUN server..

TURN: giving up

Traversal Using Relays around NAT (TURN) is simply just passing traffic through a relay server, with both sides speaking to it outbound. This works mostly everywhere, but since someone has to run a server that should be unnecessary and you have to eat the added latency of every packet detouring through a third party, this really sucks.

ICE: trying everything

Interactive Connectivity Establishment (ICE) accepts that no technique is reliable and tries all of them in order of preference. Consider everything: direct connect, STUN‐discovered external address, a TURN relay), exchange the list with the other side, and throw shit at the wall until something works. This is what WebRTC does, and it’s the best you’ll get on today’s internet. But we’ve replaced a simple direct connection with, mostly, external infrastructure.

The long‐term solution that wasn’t

The principal “long-term solution” in the works that RFC 1631 was referring to was IPv6, and it was supposed to fix this; give everyone a real globally unique address and obviate NAT. However, the sigmoid function of IPv6 adoption seems to be stalling out too early, and even where it is implemented, many ISPs and institutional networks keep doing NATy stuff out of inertia and even more misguided security thinking: firewalls that refuse inbound because that’s we’re used to NAT doing that, or completely unnecessarily applying actual NAT to IPv6  — often deploying Unique Local Addresses (fc00::/7) the way they use private RFC1918 space on IPv4 — which is baffling to me.

The consequences for the Internet

There’s lots of things you can blame for killing the open Internet, but I think NAT was one of the earliest. Running a server used to be trivial: run an executable, tell people your address, done. Now, if you’re lucky, you probably have to configure port forwarding, which you often can’t even do if you’re behind CGNAT or on an institutional network.

It also trained everyone to think client‐server is natural. “My device talks to The Cloud which talks to other devices” feels normal, when that feeling originated as an artifact of address scarcity. The problem the people in the XKCD comic at the top are facing is the absurdity of trying to establish a one-to-one communication using only outbound connections on both sides. Even more ironic is that NAT got normalized as a security feature  — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.

NAT certainly isn’t the only reason why the modern internet is full of centralized walled gardens, but it was the first — it’s why it’s hard to send a file to someone, it’s why you don’t run your email on your own computer, and why running your own services at all is difficult and often expensive (if you can’t port forward from your own internet connection, you have to buy a VPS instead of using hardware you already have).

Every public request to one of my sites used to go through a Cloudflare tunnel. I had a cloudflared deployment in my cluster, some routing rules, and everything just worked. And it was free! But that bugged me. TANSTAAFL right? The whole point of selfhosting is to not rely on big cloud company, and there are few bigger than Cloudflare. And Cloudflare’s tunnels decrypt every single packet, so they see everything you do. I really don’t like that.

So I’ve replaced Cloudflare tunnels with Erwan Leboucher’s towonel, a selfhosted tunnel implementation. I still have my DNS on Cloudflare, but no data is moving through them any more.

...

Self hosted trail mapping and GPS tracking with Wanderer

@selfhosted

I deployed an instance of Wanderer and defined a route in preparation for my upcoming trip to The Great Smokey Mountains National Park next week. This service uses #ActivityPub but I haven't been able to follow my account from #Mastodon yet... Even so I'm glad to add this to my #selfhosted arsenal. I will be live streaming on #Owncast during my hike, and I'll also edit the footage for #PeerTube.

https://wanderer.eom.dev/trail/view/@eric@wanderer.eom.dev/7eb769b9157c8c7?share=ojps3c4mo6q0v169l14sj4i5dkje867s

I've been increasingly getting into the idea of hosting some servers for classic PC games like Counter Strike 1.6 and various Half-Life mods, but I'm curious what the consensus is for what the best options are for doing so right now.

I have some experience hosting servers at home in a "homelab" kind of context (mostly for stuff like Jellyfin, Samba, etc.), and I know how to spin up docker containers and administer a Linux computer decently for LAN use. Right now I use tailscale to access my homelab stuff remotely, but I don't know if that would work well in the context of hosting a public game server.

Generally I don't have much knowledge about safely exposing my local hardware to the wider internet for my circle of ~20 friends to join.

So basically I'm wondering what you all would do for hosting game servers if you were going to start today...

Would you use local hardware with port forwarding? Or would you go with a VPS (and if so, can you recommend one for North America)?

I currently use Borg for all my backups. To have a remote backup I placed my old Synology NAS at a family member and connected it to tailscale (via a tailscale docker container). That way I could also can do Borg backups to that remote NAS.

Though I have problems with the stability of the tailscale connection from the NAS. And honestly, I'm a bit tired to fix these problems.

I would like to have a self hosted backup solution, that can reach the synology NAS. I would like to avoid port forwarding at my family members network (for obvious reasons). I have a VPS in the internet that I can use for a common self hosted contact point (like I setup headscale there instead of using official Tailscale servers).

What would be your way for handling these remote backups?

So, just as the title says, I wanna know if anyone here uses a proxy as a way to access a private network instead of a VPN.

In my server i just use nginx to reverse proxy through different webapps, and now the time has arrived for nextcloud, now I'm thinking that I'd rather have such services more isolated from the wider web, and I like the simplicity of a proxy login. Though I am skeptical of the user/password model for proxying into a server. Afaik all proxy server logins work within that framework.

So, does anyone do this??

Edit: I know I can find a config wherever in the web, the post is more about experiences or thoughts about using a proxy instead of the common recommendation of a VPN. Thats all. :)

I was just looking to plug a new zigbee coordinator into a POE switch today, then thought - that's going to be on the wrong VLAN, or, did I trunk the uplink...?

So... that made me think - is anyone using / tried / failed to export device configs, feed it into an AI, and get it to draw out the network??