New on LowEndTalk? Please Register and read our Community Rules.
Best OS for DirectAdmin?
DA supports CloudLinux, RedHat/Centos, Debian, and FreeBSD.
I'm curious which one you feel DA runs best on. And if you vote, please comment why you voted the way you did. Looking for any pros/cons, gotchas, etc.
Which OS is best for DA?
- CloudLinux 782 votes
- CloudLinux 825.61%
- RHAT/CentOS 720.73%
- RHAT/CentOS 825.61%
- Debian 9  1.22%
- Debian 1014.63%
- FreeBSD 11  0.00%
- FreeBSD 12  1.22%
- In my experience, DA runs equally well on all supported platforms10.98%
RHEL 8 works well for it. I've had no issues to date and you get the perks of a new kernel.
Cloudlinux 8 is also nice but has a decent price tag on it.
Where is the Temple OS option?
As much as I love Debian/Ubuntu, DirectAdmin just doesn't run as perfectly on them as on RHEL-based OS. There were occasional errors when using the CustomBuild feature, and I finally switched to CentOS 8. Never tried DA on FreeBSD or CloudLinux so don't know about them.
I've also heard it runs best on CentOS
Centos 8, so you don’t have to worry about too many EOL nodes.
Cloud linux 8 if you are reselling service.
centos and cloudlinux.....works flawlessly. Haven't tried others.
Previously had issues running DA on Ubuntu - CustomBuild would stop mid-way, complaining about missing dependency or what's not.
Running DA on Debian now. It works OK. Sometimes I read the docs and told myself: God they must have developed the whole thing on CentOS/RHEL.
In all honesty though - I suppose nothing beats CloudLinux. But it's way too expensive.
Cloudlinux/CentOS 8.x all the way
Been thinking about consolidating all my web sites onto a DA system...but if it means I have to run CentOS...
I've said it before, if DirectAdmin really wants to take on cPanel and really become a legitimate competitor, they probably need to drop their support for all the different OS's and focus on just one.
Now... one in this context can mean all RHEL variants (RHEL, CentOS, CloudLinux ... all basically the same thing). Or if they want to go with a Debian based OS, that'd be fine. Or even FreeBSD.
The point is, instead of spending all of their time fixing everything to work on a plethora of OS's - just pick one and focus all of your attention on that one.
That's my opinion anyway. Not sure what they would do with users of OS's that they (would presumably) drop, but that doesn't mean it should stop them from dropping them.
I think this should serve as a notice - anyone with plans to create their own control panel system - probably just best to pick an OS and support only that OS.
In the web hosting industry I think RHEL (CentOS/CloudLinux) are probably the most popular, so that's probably where I'd lean to. Are you going to lose out to people that prefer Debian over RHEL? Sure... but how many? 3 out of 1000? At what point does it become inefficient to support a handful of users that demand a non RHEL (or whatever distribution you choose) OS?
CloudLinux has its own benefits, but a second big reason why CentOS is popular is its 10-year support cycle, versus 5 for Debian.
Or just run everything in containers? Their overheads are low and do provide some level of isolation between processes. Just a thought tho, I wonder if there are providers already does this.
I wonder why this was not suggested before! This is a great suggestion in deed.
Why don't you suggest the same on the feedback thread?
This is also a nice suggestion. But I guess it would require them to completely rewrite DA?
It's 2020. Who is so lazy to not upgrade a web hosting node for 10yrs.
It's not an enterprise app.
5yrs is a perfectly decent compromise.
CentOS, as others have suggested DA should drop support for others..
I... did... (well... on the DA forums... actually it might be in that feedback thread... I think it is, go back to August 2019 in that thread, I think I speak about that) back in June 2019:
I've never been a huge fan of DirectAdmin's custombuild - having to compile everything. But with the reliance on so many different OS's, you have to revert back to the least common denominator... which is compiling everything. Can't rely on PHP and Apache RPMs when you also support Debian and FreeBSD.
PHP is the main culprit for me - because a new version is released once a month (and a gazillion different branches at that) - and it takes a while to compile. Things like Apache and Exim are updated less often and don't really take a huge amount of time to compile. But still, if Exim were installed via RPMs, you might be looking at a 10 second upgrade compared to a 2 minute compile upgrade.
cPanel only supports CentOS...doesn't it compile as part of its Apache setup?
Although you can't use yum on debian, you can use apt (and I think it's pkg_add on FreeBSD) - can't imagine it's hard to just switch commands in a script. There must be more to it, something you can only get by compiling.
cPanel moved to EasyApache 4 some time ago where all Apache and PHP stuff was moved to RPMs (cPanel maintained RPMs). Before EA4, their EasyApache was a lot like CustomBuild and compiled everything (Apache related). The move to EA4 was a godsend if you ask me.
Correct, Debian uses apt and deb packages - and to some degree, this might actually be better. apt-get predates yum by quite a few years. Does anybody here remember "depencency hell" from the mid 90's RedHat? Just me? When Debian was released and apt-get was available that solved all of that, it was nice. Then yum came along - I think when RedHat split into Fedora and RHEL. CentOS/RHEL/CloudLinux and in general yum repositories, rely on backporting packages - the version being reported by a binary on these systems doesn't necessarily reflect the actual version of the code that is in use. Debian (Ubuntu is Debian based) tends to use updated versions and not so much backports.
But CentOS/RHEL just have a larger market share now, that's why I would suggest going the CentOS/RHEL/CloudLinux/RPM/Yum route rather than the Debian/Deb/Apt route - but in terms of principles it's tomato, tomahto.
But to support both RPM and Deb (and whatever FreeBSD uses... it's been a long, long time since I used FreeBSD and I didn't use it long) you're not really solving anything. When an update to Apache is released, DA would still have to package up an RPM, a Deb, and a pkg_add package for all of their relevant supported OS's. The point of going this route would be to streamline the process so that time wouldn't have to be invested into all of the lesser used OS packages.
How could we forget?!
May I ask you what other benefits do you see there? There are multiple reasons why most DA-related packages are compiled, but OS-support isn't one of these.
I'm not saying compilation wins there, but it's been questioned/hated so many times that I'd like to hear and understand why you've "never been a huge fan of CustomBuild".
I've heard the "speed" reason, and I cannot add anything there, OS packages clearly win on update/installation speeds
Again I'm focusing mostly on PHP ... say you need to install the intl extension to PHP, with EA4 or even the Remi repository - it's a simple matter of installing the necessary phpXX-php-intl package. But with custombuild - and with the older EasyApache 3 with cPanel - you had to recompile the whole PHP infrastructure. ... Now... Woops! Now the script needs the tidy extension... recompile everything again.
Now imagine doing all of that on 50 servers.
I suppose you could solve a lot of this by compiling shared libraries, but still once a month, you'll have to recompile the whole PHP when a new version gets released.
I will say that custombuild is more CLI oriented which makes this a bit easier. EasyApache 3 was ncurses based and that made it a bit more difficult to do in a non-interactive shell. With custombuild it's a bit more straight-forward to do this from a non-interactive shell environment.
The other issue is troubleshooting. Compiling something may depend on certain libraries being installed. What if someone doesn't have those libraries installed? Custombuild or whatever is managing the compiling has to be aware of what libraries are missing and also compile those libraries (which may require further libraries to be compiled... dependency hell). Pre-packaged binaries would seem to take care of all of that by forcing the install of necessary packages that need to be installed alongside a package.
Compiling definitely gives you more flexibility. But I'm more concerned with efficiency. 9 times out of 10 (999 out of 1000?) people don't need anything extraordinary in their PHP or whatever they are compiling. A pre-packaged binary is going to work for the vast majority, it's going to be faster to install, and it's going to be easier to troubleshoot. But at the end of the day, you can always compile something if you need to. 9 out of 10 DA users will never need to compile anything special into PHP, but that 1 out of 10, they can still do that. Why do those 9 people have to suffer the inefficiency of the system just to accommodate that 1 person?
Compiling everything just makes me think of old systems. Package systems and repositories have been shown to be highly stable and just feels more modern.
Not true Please try doing:
./build set_php imap yes
It won't recompile whole PHP to load imap extension. Any ext/ from PHP can be built as dynamic loadable module. See the source file of CB for this.
It's similar with RPMs, if they mess up the libraries, ldconfig will have issues. PHP from RPM:
# ldd /usr/bin/php linux-vdso.so.1 => (0x00007ffe23bd8000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fee87ed1000) libargon2.so.0 => /lib64/libargon2.so.0 (0x00007fee87cc9000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fee87aaf000) libedit.so.0 => /lib64/libedit.so.0 (0x00007fee87872000) libncurses.so.5 => /lib64/libncurses.so.5 (0x00007fee8764b000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fee87421000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fee8711a000) libz.so.1 => /lib64/libz.so.1 (0x00007fee86f04000) librt.so.1 => /lib64/librt.so.1 (0x00007fee86cfc000) libm.so.6 => /lib64/libm.so.6 (0x00007fee869fa000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fee867f6000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fee865dc000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fee86272000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fee86025000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fee85d3c000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fee85b09000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fee85905000) libssl.so.10 => /lib64/libssl.so.10 (0x00007fee85693000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fee85230000) libc.so.6 => /lib64/libc.so.6 (0x00007fee84e62000) libfreebl3.so => /lib64/libfreebl3.so (0x00007fee84c5f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fee84a43000) /lib64/ld-linux-x86-64.so.2 (0x00007fee88817000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fee8482d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fee84607000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fee843f7000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fee841f3000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fee83fcc000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fee83d6a000)
The idea was quite opposite, to give more flexibility to the customers. For example, PHP 7.4.11 is released today, even if it is not on DA mirrors, you just wget it to custombuild folder, change versions.txt and run "./build php" - you'll get it installed, even without the package on DA servers, and it'd have all the patches/configs needed. If we go RPM way - customers would need to have the knowledge and manually build that RPM there. Yum would interfere with that custom-version installed. At this time any user can get any version installed/patched etc. without lots of knowledge. Your mentioned "intl" extension is a good example as well. What would you do if it's simply not available as RPM for your PHP installed using yum?
I see lots of pros and cons in both systems. There is no clear winner to me, but I could be wrong there, of course
I've been using the Remi repository to run PHP on our DirectAdmin server since we started investigating DA last summer.
Remi actually releases a new version of PHP before it gets to the php.net website (at least for me). So whoever is maintaining that repository really stays on their toes.
I'm just not a fan of compile everything. Sorry that I can really give a reason as to why - other than it just feels old. If I can install everything I need with RPMs/yum or DEBs/apt - then I'm going to do that. I'm not going to waste my time compiling it. Personal preference I suppose.
Are you sure they have lsphp (LiteSpeed SAPI) mode there? I don't also think they backport patches for issues like https://bugs.php.net/bug.php?id=77443 (PHP-FPM). So, we'd either need to provide previous versions with bugs or pack our own RPMs. Did they have CentOS8 packages immediately after release of CentOS8? (DA beta was announced at that time, for example).
Same could be said about exim - 4.94 is really buggy, but we've backported 3 unreleased patches just to 'make it work'. We've reported all of these as well. I guess 4.94 is not yet available in the other control panel you named.
No, you have your point there Speed, updates using OS package manager etc. As I said, I see lots of pros there too.
What is your idea of "enterprise", then? A previous company put tons of resources into their website that ran certain versions of mysql and php. It would require a ton of resources to constantly be updating it to stay current. So "enterprises" will run super old servers because they worked and it's a bunch of hassle to constantly be upgrading. Enterprises are NOT putting long term stuff on latest stuff.
More than 5 years is a MUST, 10 years gives ample time to plan for upgrades and migration. Think 7 years is good target.
We may have our differences but agree wholeheartedly here. For enterprise stability is much more important than grabbing the latest & greatest, with its' inherent risks.
(I keep looking for a viable replacement for a reliable e-commerce application that runs best on PHP 5.3 Alternatives don't have the required feature set or require major resources.)
DreamHost had an interesting post back in 2013 about how lifecycle drove them to leave Debian for Ubuntu. Lifecycle times were different then, but it was the dominant concern.
They have 20,000 servers...even if they're counting each VPS as a server, I can see why having the longest possible upgrade cycle would be attractive.
My comment was directed at DirectAdmin shared hosting providers.
If you have a legacy website that your devs cannot port over to php 7.2, you have worse problems ahead.