July 2026 – Effectively the end of the DirectAdmin Legacy License

Please select the option that best reflects your current situation:


  • Total voters
    13
@Richard G is correct . MariaDB 10.5 is EOL, and while AlmaLinux promises support until 2032, that doesn’t mean they’re on the hook for fixing everything. They’ll backport critical updates if MariaDB releases them, but beyond that, AlmaLinux’s support is limited. They’re not legally required to patch every vulnerability or fix every issue, so relying on this isn’t the same as using actively supported software.

-------------------

As for @virtio (the thread starter), their point really hasn’t been addressed yet. The issue wasn’t about our sustainability choices, but how we went about them. Referring to the codebase as "legacy" without offering a clear roadmap was a huge pain-point, especially for large-scale operations.

When you’re dealing with big infrastructure, "maybe" or "you might get more" isn’t enough to make decisions on. It could even get you in hot water with regulators. @virtio we more than accept the premise of your post and thank you for your professionalism and willingness to see things from our side. In return for that, we will do the same, and publicly admit you could of called us "amateur hour" and been justified in doing so. Thanks for being a class act.
 
Once you are done with the mutual flattery, could we please get a precise answer as to how Directadmin will handle the upcoming database issue in the future? If at all?
 
If I remember correctly this was tested, should be even a thread about it somewhere here. Somebody installed MariaDB 10.11 manually and got a notice that this was not allowed.
Maybe it's possible to install some other database, but then the connection with DA is lost again (managerble, user can create databases etc).

So that is why I ask about the idea previously made somewhere, to allow the OS updates for MariaDB once 10.6 is EOL. So users can choose either keep running an EOL version or choose your suggestion of database on another server, or downgrade to 10.5 and have the OS keep doing the updates.
Either way, this should be no issue for DA and no extra development. And would make life easy for people who would like to keep things as they are now for a bit longer. Because with the EOL date of Alma 9 in 2032 it's end of story anyway, probably even sooner depending on which updates are coming (or rather not).

If I remember correctly the idea of giving users choice to have the OS do the updates after EOL of the database was under consideration.
As someone who also maintains my own stack where I have to decide which versions of MariaDB to support, I can see both sides - DA side and legacy end users' sides.

The act of switching MariaDB server versions accounts for only 10% of dev work. 90% is testing and understanding every conceivable configuration and testing all deprecating and newly introduced MariaDB server variables and changes in behaviour that come with different major MariaDB versions and then making sure it fits in with the framework and routines for your stack (DA). That work gets larger as MariaDB major versions keep incrementing from 10.6, 10.11. 11.4. and 11.8 for LTS releases.

I don't have legacy DA license (before my time), but I can guess 10.11 was probably programmatically blocked just to protect end user from screwing up their system as DA folks probably haven't tested every conceivable config and issue with MariaDB 10.11 and legacy software. It's what I do with my own stack to block no-yet tested MariaDB major versions with my stack to prevent users from screwing up their system.

The alternative would be for DA to remove the routine that blocks it, but have a check box that users agree it can break and render their legacy DA's MariaDB unusable and they're on their own without any support from DA to fix anything that breaks for untested MariaDB versions. The legacy DA users who are adventurous can test newer MariaDB major versions and see what breaks etc.

Just my AUD$0.02
 
And somehow I still provide PHP7.4 for customer with warning (EOL) to ensure no complain later when something go wrong. 😒

Like some filter ( filter_var ) can bypass some options.
 
could we please get a precise answer as to how Directadmin will handle the upcoming database issue in the future? If at all?
There will be no changes for the legacy license holders. Without a new license DA will not work with modern MariaDB/MySQL. Servers with legacy licenses can continue using MariaDB 10.6 forever.
 
Servers with legacy licenses can continue using MariaDB 10.6 forever.
Does that mean that legacy licenses will be supported forever, too? Asking for a friend.

NB. I know they won't work with newer OS's (e.g. Debian 13 and beyond), but I'm just trying to figure out the forever part.
 
Does that mean that legacy licenses will be supported forever, too? Asking for a friend.
Define "supported"?

IMHO in software land "forever" means "as long as it's available and no hard EOL is declared or a company does not go broke or get's sold".
So that's what I learned in the past years what forever or lifetime means.

The legacy DA users who are adventurous can test newer MariaDB major versions and see what breaks etc.
They already can do that, but if they do, the connection with DA will instantly get disconnected. Which of course is logical because DA does not want to fix issues caused by adventurous users.
Which is also the reason I won't post the option on how to do that in public. It has already been mentioned publicly somewhere which is how I know, but I won't repeat that again.
If somebody wants to know, they can pm me. But be aware it will instantly break current database connections with DA and causing a very big chance to mess things up, so use at your own risk!!
 
@LawsHosting Yes, you’re free to keep running the legacy license as long as it works for you. Not too different than those asking how long they can stay on the CentOS 6 or FreeBSD builds. Forever = as long as it works for you.
 
Back
Top