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.
> I use it for years to achieve HA for personal mail servers and will now have to look for alternatives
Yeah, Dovecot seem to be going hardline commercial. Basically the open-source version will be maintained as a single server solution. Looks like if you want supported HA etc. you'll have to pay the big bucks.
There is a video up on YouTube[1] where their Sales Director is speaking at a conference and he said (rough transcript):
"there will be an open source version, but that open source version will be maintained for single server use only. we are actually taking out anything any actually kinda' involves multiple servers, dsync replication and err some other stuff. so dovecot will be a fully-featured single node server"
Have you looked at Stalwart[2] as an alternative ?
I usually fix those kind of problems by running the offending software in a docker container, with the correct version. Sometimes the boundaries of the container create their own problems. Dovecot 2.3 is at https://hub.docker.com/r/dovecot/dovecot/tags?name=2.3
Indeed, container live migration is limited and a bit unclear on "network devices" - bridged interface is network device or not?
Bit ironic, that even with using CRUI, which AFAIK was created by the same Virtuozzo guys which provided OpenVZ back then, and that VEs could live migrate, was personally testing it in 2007-2008. Granted, there we no systemd by that days, if this complicates things. And of course required their patched kernel.
> Live migration for containers
For containers, there is limited support for live migration using CRIU. However, because of extensive kernel dependencies, only very basic containers (non-systemd containers without a network device) can be migrated reliably. In most real-world scenarios, you should stop the container, move it over and then start it again.
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).
If being used in a CTF counts, then running latest docker with no extra privilege and non-root user on a reasonably up-to-date kernel meets the definition of secure I think. At least for what I have seen, this kind of infrastructure is pretty common in CTF.
> 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
systemd-networkd sets up a LAN interface, which Kea then serves DHCP for.
CoreRAD is about the same thing, but for NDP instead of DHCP.
I could have used systemd-networkd for serving DHCP and NDP, but prefer to use separate modular privilege-separated deamons, especially if I get memory safety too.
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].
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/
There is bund.de for the federal government, with e.g. the interior ministry (Bundesministerium des Innern) at bmi.bund.de. But personenstandsrecht.de has nothing in the domain name or even the whois to indicate that it really is part of the interior ministry as it claims. There are links to it from bmi.bund.de so presumably...
Here they do have such domains: .gc.ca for the Government of Canada, and .gouv.qc.ca for the Québec government. But annoyingly they both seem to be moving towards canada.ca and quebec.ca, respectively. There's even a whole .quebec TLD now that they could use, but no.
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.
It's not that complicated actually. There are already companies who establish local companies that function as intermediary for hiring local people. Alternatively, you can setup your own company that will employ you, pay the local taxes etc. and the company that actually you work for will pay your company for purchasing services.
Deel, Oyster HR and Papaya Global are examples for the first solution.
Though VAT is one of the easier things in practice once you have everything running. Granted I used an accountant to deal with all the taxes, which totally is worth the cost.
As stated, I am only focused on employment, not freelancing. See also parallel discussion with challenges of contractor vs employee and false self-employment.
Disclaimer: IANAL and I am not a tax accountant. This is not tax advice. See a local professional.
Direct employment by a U.S. company is possible and legal in Europe/EU. The company doesn't need to establish a local branch, but needs to get a tax number (so that the tax office can track the tax payments you make every month, because instead of automatic withholding of taxes typically done by a local employer, you will be responsible to do them yourself). Talk to a local tax accountant, they can typically set your U.S. employer up with local social security and the tax office. You will be taxed according to your local tax rates, same for social security contributions. Often that includes "employer contributions", which are charged on top of your "gross" salary. So the cost to your employer is your gross salary plus employer contributions to social security, which includes pension insurance, disability insurance, accident insurance, labor fund, and sickness insurance. According to [1], this can range between 19.21% to 22.41% on top of your gross salary.
Generally, setting up a tax number and getting enrolled in the social security system is a pain and (depending on the country and local government office employees) may require documents signed by high-level people of the company. Therefore, not a lot of U.S. companies are likely willing to go down that road for a single employee.
You are out of luck then, there is no legal framework for employment cross-border anywhere. Maybe in Dubai with their remote work visa giving you 0% taxes but that would require a relocation there.
Not true at all! My (EU) tax form has a special field just for this case - income from out-of-EU employment... (and because of tax residency rules that applies only if I live there)
And there definitely is a legal framework - this has very exact rules specified by the bilateral tax/trade agreements, every combination of western countries has them, and many non-western countries too.
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...