Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Best OS for DirectAdmin?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Best OS for DirectAdmin?

raindog308raindog308 Administrator, Veteran

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.

https://directadmin.com/install.php

Which OS is best for DA?
  1. CloudLinux 783 votes
    1. CloudLinux 8
      25.30%
    2. RHAT/CentOS 7
      20.48%
    3. RHAT/CentOS 8
      25.30%
    4. Debian 9
        1.20%
    5. Debian 10
      15.66%
    6. FreeBSD 11
        0.00%
    7. FreeBSD 12
        1.20%
    8. In my experience, DA runs equally well on all supported platforms
      10.84%
«1

Comments

  • FranciscoFrancisco Top Host, Host Rep, Veteran

    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.

    Francisco

    Thanked by 1MichaelCee
  • 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

  • Windows NT4

    Thanked by 1DA_Mark
  • Centos 8, so you don’t have to worry about too many EOL nodes.

    Cloud linux 8 if you are reselling service.

  • HostMayoHostMayo Member, Host Rep

    centos and cloudlinux.....works flawlessly. Haven't tried others.

  • klikliklikli Member
    edited September 2020

    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 :)

  • handyhosthandyhost Member, Host Rep

    CentOS8

  • raindog308raindog308 Administrator, Veteran

    Been thinking about consolidating all my web sites onto a DA system...but if it means I have to run CentOS...

    image

  • 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?

    Thanked by 1MechanicWeb
  • raindog308raindog308 Administrator, Veteran

    @sparek said: I think RHEL (CentOS/CloudLinux) are probably the most popular,

    CloudLinux has its own benefits, but a second big reason why CentOS is popular is its 10-year support cycle, versus 5 for Debian.

    https://linuxlifecycle.com

  • ericlsericls Member, Patron Provider

    @sparek said:
    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?

    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.

    Thanked by 1MechanicWeb
  • MechanicWebMechanicWeb Member, Patron Provider

    @sparek said: 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.

    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?

    @DA_Mark ?

    @ericls said: 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.

    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..

  • @MechanicWeb said:
    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?

    @DA_Mark ?

    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:

    https://forum.directadmin.com/threads/installing-upgrading-compile.58065/

    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.

  • raindog308raindog308 Administrator, Veteran

    @sparek said: 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.

    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.

    Thanked by 1raindog308
  • @sparek said: Does anybody here remember "depencency hell" from the mid 90's..

    How could we forget?! :#

    Thanked by 1vimalware
  • @sparek said: 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.

    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 :smile:

    Thank you!

  • Mostly speed.

    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.

    Thanked by 1MechanicWeb
  • @sparek said: 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

    Not true :) Please try doing:
    ./build set_php imap yes
    ./build php_imap

    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.

    @sparek said: Compiling something may depend on certain libraries being installed. What if someone doesn't have those libraries installed?

    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)

    @sparek said: Compiling definitely gives you more flexibility.

    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 :smile:

    Thanked by 1coolice
  • 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.

  • @sparek said: 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.

    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.

    @sparek said: Personal preference I suppose.

    No, you have your point there :smile: Speed, updates using OS package manager etc. As I said, I see lots of pros there too.

    Thanked by 1coolice
  • @vimalware said:
    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.

    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.

  • AlwaysSkintAlwaysSkint Member
    edited September 2020

    @TimboJones
    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 :open_mouth: Alternatives don't have the required feature set or require major resources.)

    Thanked by 1skorous
  • raindog308raindog308 Administrator, Veteran

    @TimboJones said: More than 5 years is a MUST, 10 years gives ample time to plan for upgrades and migration. Think 7 years is good target.

    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.

    https://www.dreamhost.com/blog/change-is-in-the-air-dreamhost-upgrades/

    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.

    Thanked by 2TimboJones vimalware
  • @TimboJones said:

    @vimalware said:
    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.

    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.

    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.

    Thanked by 1TimboJones
Sign In or Register to comment.