stratself

joined 3 months ago
[–] stratself 1 points 2 hours ago

Nextcloud forked from the old PHP-based ownCloud stack, while Opencloud forked from the Infinite Scale Go-based stack. It also by default preserves the filesystem hierarchy on your server without needing a database, using a storage driver called PosixFS.

The Windows clients currently do support selective syncing so it is on-par with OneDrive. Android client looks to be forked from old Owncloud, and has offline availability too.

[–] stratself 1 points 4 days ago

First, I recommend telling your script to check whether the IP has changed before publishing a new one. This may alleviate some issues like ratelimits or confusion from your dynDNS provider.

Secondly, if the problem persists, you may wanna use another dynDNS provider and figure out their API. My recommendation is deSEC, and they have some client-side tools to auto-update the IP too.

Thirdly, you may wanna find out exactly why there are intermittent failures. Does your Jellyfin's public IP address changes often? If so, your DNS caches may have trouble updating to the new IP address, or the DNS provider doesn't have time to fully propagate its changes to the world wide web. nslookup yourdomain from those machines when the issue happens, and see what's up. Or maybe, the dynDNS server location is too far away from your country. causing DNS resolution to timeout and fail.

For your own domain part, well: you buy a domain through a registrar, and most of the time they also act as a DNS provider where you can update DNS records. dynDNS is just a set of tools to easily do this when you have changing IP addresses, and how it works depends on the DNS provider's API. If you understand their APIs, you can roll out your own script pretty quick. But buying a domain is usually unnecessary to fix DNS issues

[–] stratself 4 points 4 days ago

Try Syncthing with IgnoreDelete but note that it's unrecommended. Maybe use Syncthing as an append-only store

[–] stratself 3 points 5 days ago (1 children)

due to it missing ideal features

what features do you want? kindly elaborate


XMPP with Snikket could be an easy solution. If you don't want to talk to the wider web make sure to disable federation.

[–] stratself 3 points 1 week ago (1 children)

It's entirely possible. If the 2 domains are different, you should look into SNI routing using the TCP router instead of HTTP. With the tls.passthrough flag, encryption is kept intact until it reaches the second proxy.

[–] stratself 3 points 1 week ago (1 children)

Pihole runs on dnsmasq right? Maybe you could create a cronjob to copy the underlying dnsmasq.conf to other Piholes

[–] stratself 2 points 1 week ago

Ah, I see. Well I'm glad you found PiHole useful and stick to using it anyhow!

[–] stratself 2 points 1 week ago (2 children)

What issues did you have reverse-proxying? For me it was just as simple as pointing to port 5380. Other ports like 53 could be passed on with a layer-4 router

What about the login issues? I'd hope they'll be integrating with OIDC or some other auth mechanism, but for now managing 2FA creds should make do

[–] stratself 29 points 1 week ago (2 children)

Off the top of my head:

  • Allows using DoH/DoT/DoQUIC/recursive upstreams without installing extra packages (unbound, cloudflared, etc)
  • Allows acting as a DoH/DoH3/DoT/DoQUIC server alongside normal DNS over UDP and TCP
  • Allows configuring SOCKS/HTTP proxies for forwarders
  • Act as authoritative zone server with DNSSEC signing
  • Allows custom responses via plugins (e.g. conditional responses based on client's IP addresses)
  • Accept PROXY Protocol to forward client IPs from trusted load balancers
  • All the clustering and zone transfers magic
  • DNS64

It really dives deep into the inner workings of DNS and does pretty much anything Pi-Hole does, with many more security and QoL features. Although the UI may feel a bit dated, I'd recommend it to anyone running their own homelab infrastructure beyond just adblocking

 

Technitium DNS Server (TDNS) has gotten a new release with many awesome features: TOTP authentication, an upgraded .NET library, and many security and performance fixes.

But most important of all, it now supports clustering. A long-awaited feature, this allows Technitium to sync DNS zones and configurations across multiple nodes, without needing an external orchestrator like Kubernetes, or an out-of-band method to replicate underlying data. For selfhosters, this would enable resilience for many use cases, such as internal homelab adblocks or even selfhosting your public domains.

From a discussion with the developer and his sneak peek on Reddit, it is now known that the cluster is set up as a single-primary/multiple-secondary topology. They communicate via good-old REST API calls, and transported via HTTPS for on-the-wire encryption.

To sync DNS zones (i.e. domains), the primary server provisions the "catalog" of domains, for secondary ones to dynamically update records in a method known as Zone Transfers. This feature, standardized as Catalog Zones (RFC9432), were actually supported since the previous v13 release as groundwork for the current implementation.

As an interesting result, nodes can sync to a cluster's catalog zone, as well as define their own zones and even employs other catalog zones from outside the cluster. This would allow setups where, for example, some domains are shared between all nodes, and some others only between a subset of servers.

To sync the rest of the data such as blocklists, allowlists, and installed apps, the software simply sends over incremental backups to secondaries. The admin UI panel is also revamped to improve multi-node management: it now allows logging in to other cluster nodes, as well as collating some aggregated statistics for the central Dashboard. Lastly, a secondary node can be promoted to primary in case of failures, with signing keys also managed within for a seamless transition of DNSSEC signed zones.

More details about configuring clusters is to be provided in a blogpost in the upcoming days. It is important to note that this feature only supports DNS stuff, and not DHCP just yet (Technitium is also a DHCP server). This, along with DHCPv6 and auto-promotion rules for secondaries, is planned for the upcoming major release(s) later on.

As a single-person copyleft project, the growth of this absolute gem of a software has been tremendous, and can only get better from here. I personally can't wait to try it out soon

Disclaimer: I'm just a user, not the maintainer of the project. Information here may be updated for correctness and you can repost this to whatever

[–] stratself 3 points 1 week ago (1 children)

Just found out someone else has a similar thing too:

https://github.com/juhovh/tailguard

It seems more flexible and can be used site-to-site, for anyone interested

66
submitted 2 weeks ago* (last edited 2 weeks ago) by stratself to c/selfhosted@lemmy.world
 

Hi all, I made a simple container to forward tailscale traffic towards a WireGuard interface, so that you can use your commercial VPN as an exit node. It's called tswg

https://github.com/stratself/tswg

Previously I also tried Gluetun + Tailscale like some guides suggested, but found it to be slow and the firewall too strict for direct connections. Tswg doesn't do much firewalling aside from wg-quick rules, and uses kernelspace networking which should improve performance. This enables direct connections to other Tailscale nodes too, so you can hook up with DNS apps like Pi-hole/AdguardHome.

I've shilled for this previously, but now I wanna promote with an actual post. Having tested on podman, I'd like to know if it also works on machines behind NATs and/or within Docker. Do be warned though that I'm a noob w.r.t. networking, and can't guarantee against IP leaks or other VPN-related problems. But I'd like to improve.

Let me know your thoughts and any issues encountered, and thank you all for reading

[–] stratself 6 points 2 weeks ago

Thanks for posting this here. I'm not sure what to think about this, just set up mkdocs-material with huge customizations, including the macros plugin and tons of CSS. So it'd be tedious to eventually migrate to the new "component system" as they say.

Welp, should've gone with a barebone SSG and configured what I want. Feels like I'm kinda stuck in no man's land now.

[–] stratself 2 points 2 weeks ago (1 children)

Hey, I'm glad you got it working, yeah Continuwuity is still a drop-in replacement right now so all is good. I also did a drop-in a few months back with zero hassle at all. Most env vars and config options weren't changed, but I redid my continuwuity.toml file just to be sure.

I'd recommend joining the announcement room to keep track of updates, and the community room for support too

 

Hi all. Per the title, I'm looking for something that:

  • Can run as an unprivileged user inside a container

  • Allows OpenID Connect authentication for a multiuser setup

  • Doesn't take hostage of my CPU

Homarr and Dashy are featureful solutions, but they can't run unprivileged in docker. Dashy closed this issue, but in fact it's not resolved. Meanwhile Homarr does work with UID/GID env vars, but starting as root and dropping capabilities is not the same as defining user: 1234:1234 from the get-go. Furthermore, they are really heavy node apps, which kinda deter me from deploying.

I neither wanna use my reverse proxy with forward auth or having an extra oauth2-proxy container, so Organizr (using forwarded auth headers) or Homer/Homepage/bunch of static pages behind a reverse proxy is out of scope.

Feature-wise I'm just looking for a beautified link keeper, preferably with multiple dashboard mapped to different user groups (ideally it could be done via custom OAuth metadata/claims). Fancy plugins like RSS and weather are not needed, but appreciated.

With all that said (and sorry if I'm too choosy), is there a current solution that fits the bills above? My IDP's UI is quite rudimentary, but I can resort to using it as a "homepage". I wanna thank in advance for any guidance

P/S: Seems like most dashboards fall into two categories - bloated fancy apps, or dead simple frontpages. It'd be nice to have something inbetween.

view more: next ›