tok1

True for API but you can do DynDNS updates (RFC 2136), TSIG-authenticated on a per-zone basis. [1]

Can even be controlled quite granularly with a Lua-based updatepolicy, if you want e.g. restricting to only the ACME TXT records. [2]

[1] https://doc.powerdns.com/authoritative/dnsupdate.html

[2] https://github.com/PowerDNS/pdns/wiki/Lua-Examples-(Authorit...

Thank you!

Not only that: Dovecot 2.4 will also remove the functionalities of dsync, replicator and director [1]. This is frustrating and a big loss as these enabled e.g. very simple and reliable two-node (active-active) redundant setups, which will not be possible anymore with 2.4.

I use it for years to achieve HA for personal mail servers and will now have to look for alternatives -- until then will stick with Debian Bookworm and its Dovecot 2.3.

[1] https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2....

I think what you are asking falls into "cluster member evacuation and re-balancing" [0], combined with live migration [1] with minimal downtime.

[0] https://linuxcontainers.org/incus/docs/main/howto/cluster_ma...

[1] https://linuxcontainers.org/incus/docs/main/howto/move_insta...

Fun fact, Incus is being used as underlying infrastructure for the NorthSec CTF, i.e. in an "as hostile as it can get" environment. If you have close to a hundred teams of hackers on your systems trying to break stuff, I think it speaks for Incus and its capabilities regarding isolation and limits.

In case you are interested, Zabbly has some interesting behind-the-scenes on Youtube (not affiliated).

> Instead, its documented approach to running as some other account is to add some of the superuser's privileges to Kea [...]

Not disagreeing, just want to mention that Kea can run fine without privileges, which is also documented at the link provided. Key is to use DHCP relaying, a technique which becomes relevant quickly in larger setups anyways because you cannot (or don't want to) give the DHCP server access to all subnets: Instead of the DHCP server(s) processing local requests, DHCP relaying agents encapsulate and unicast-forward the whole DHCP request-response traffic to centralized DHCP instance(s). Those relaying agents (on switches/routers) do require privileges but potentially posing a smaller attack surface due to being much simpler. Sadly, ISC has not made a successor dhcprelay as part of Kea, but luckily systemd-networkd implements the RelayTarget parameter, adding this capability (at least for IPv4).

Running a router built with systemd-networkd and kea myself, and I quite like both, even though I have not integrated them with each other. Would you be willing to share some details on how you use these components? Especially corerad as I am not familiar with it and wonder on the why+how, considering networkd does NDP. Thanks

I am not familiar with Firehol, so I might be missing something, but isn't this already solved in a (potentially) more powerful, mature and standardized way by DNS RPZ (Response Policy Zones, [1])? Well-established resolvers like Unbound fully support integrating multiple block lists (like oisd.nl, energized.pro, abuse.ch, etc), keeping them up-to-date via zone transfers or HTTPS download, see [2].

[1] https://www.isc.org/rpz/ [2] https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering...

One could almost wonder if the explosion of gTLDs in the 2010s has been pushed by registrars as they were seeing Big Money. In (my personal) retrospective, the value for Internet users and their actual usage is vanishingly small--compared to the downsides of massively increased phishing risks and, as you mentioned, the need for companies/brands to nowadays having to register (and pay for) a gazillion of irrelevant TLDs, merely for brand protection and abuse prevention.

This "trust aspect" implied (or assured?) by certain TLDs, or for the non-US world by second-level domains under ccTLDs, has been, interestingly, completely missed by several countries in the early Internet days, including fairly large ones like e.g. Germany: Annoyingly, you cannot identify a federal agency or otherwise "official" website by its domain--no trailing .gov.de or the likes, it will alway be "just" ending in .de, which makes things like phishing but also deception (by implying a certain level of authority but in fact selling services from a private entity) unnecessarily easy. This is contrary to other countries' .gov.uk, .gv.at, .edu.au, etc. Although created for different reasons, I think, the Public Suffix List gives some indication of which countries enforce such namespaces (or did), see https://publicsuffix.org/list/

As stated, I am only focused on employment, not freelancing. See also parallel discussion with challenges of contractor vs employee and false self-employment.

I don't want to sound negative but with current tax legislation in most EU countries, this is far more complicated than it may sound, at least to do it lawfully. Not impossible but in many cases, it requires a legal entity in your home country to be fully employed (i.e. not freelancer-based).

I investigated a somewhat related scenario: Being employed at a German legal entity with an already-remote contract and relocating to a neighboring EU country for permanent remote work. Turns out to be complicated and quite unattractive for your employer to support this, due to national tax+labor laws, potentially mandatory social insurance, etc.

Would appreciate any hints though.

No disagreement in general, but to your point of infrastructure routers (assuming you refer to ISP and Internet backbone infrastructure):

Having worked in ISP security, IMHO a years-long uptime of such critical components is nothing to be proud of (anymore). Quite the contrary, those are complex components, so if you care about security you have to regularly patch them, including occasionally required reboots. Just look at the list of security advisories of relevant vendors (Cisco, Juniper, Nokia/Alcatel-Lucent, etc), you can find scary vulnerabilities! Granted, "rebooting" a core router is more nuanced than a regular PC (you can e.g. reboot one management engine of a pair; or just a line card; etc), so it does not always mean that the entire traffic stops because of it.

Oh and btw. your network design should be able to cope with such necessary reboots, otherwise you have a single point of failure.

Regards

Absolutely love syncthing, and migrated to it after using Seafile for several years. I also have quite some personal/business experience with iCloud and OneDrive, and syncthing is (mostly) superior.

My wishlist for syncthing though, in prioritized order:

1. support for symlinks, to be able to sync files/folders that live outside of syncthing dirs. Some files I’d like to sync are in fixed locations that I cannot or don’t want to change, and Seafile allowed me to simply symlink them into an already synced dir. The counter-argument in GitHub discussions is having to distinguish between syncing symlink destinations vs. the symlink „as symlink“. For my situation that would be overthinking (as I’d never have the second use case) but I understand the hesitation, sadly.

2. provide a smart versioning/rollback solution leveraging ZFS snapshots, as my file server as participating node already creates rolling snapshots

3. (nice to have) mark certain directories as „sparse“, to sync data only when really accessed. Similar to what OneDrive provides