stratself

joined 3 months ago
[–] stratself@lemdro.id 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@lemdro.id 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@lemdro.id 2 points 1 week ago

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

[–] stratself@lemdro.id 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@lemdro.id 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@lemdro.id 2 points 1 week ago

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

 

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@lemdro.id 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@lemdro.id 7 points 2 weeks ago (1 children)

I find it odd that a report for the proprietary Github platform takes the newsletter's spotlight, it's not very relevant. I'd much prefer if the writer could expand his thoughts on those new version releases or featured blogposts, especially the ones he finds interested in.

[–] stratself@lemdro.id 4 points 2 weeks ago

If it ain't broke, don't fix it. I think it's better hooking up Element Call to your current setup, and remove Element Web if you can BYO client.

For a more lightweight alternative, I personally find continuwuity to be reasonably stable for the specs you mentioned. It does admin tasks in an #admins room, use an embedded database, and has no client UI so less containers needed. So continuwuity + EC should be able to run under the constraints you mentioned

The lightest would still be any XMPP server, though its functionality does differ from Matrix overall

[–] stratself@lemdro.id 2 points 3 weeks ago (1 children)

To make it even simpler, apk -U upgrade

[–] stratself@lemdro.id 3 points 1 month ago* (last edited 1 month ago)

Hi,

The client IP problem is a longstanding issue in podman's virtual bridge networks.

As a workaround I'd run HAProxy rootless, using the pasta networking mode as that one allows seeing native client IP. With pasta's -T flag (see docs) I'd forward traffic to another caddy container binding to 127.0.0.1:8080 or something similar.

This would coincide with your firewalld/HAProxy port-forwarding setup, but it has more rootlessness to it. It's still not perfect and you'd still need to tweak sysctls, but I hope it may be useful

[–] stratself@lemdro.id 2 points 1 month ago

You'll need a TURN server to relay calls and provide signalling capabilities, which is needed most of the time. Here's Synapse docs on it, and I'll probably use coturn:

https://element-hq.github.io/synapse/latest/turn-howto.html


There's also this new technology called Element Call, which uses a diffent tool called LiveKit. You should check it out too

https://github.com/element-hq/element-call/blob/livekit/README.md

 

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 ›