Opinion of a huge hosting provider

freehost

Verified User
Joined
Jan 13, 2020
Messages
10
Just moved over to DA from a piece of crap called cpanel. I wrote a custom script that converted 90000 (yes, ninety thousand) accounts in a matter of hours. All accounts are now valid in DA and perfectly usable with site builder and software installer plugins which I have been providing. One-click webmail login is working perfectly well, unlike one-click login to phpMyAdmin -- stupid DA creates mysql grants for single signon user 'da_sso_xxx'@localhost (seemingly hardcoded) regardless of my remote mysql configuration, that makes an user see blank page instead of his desired list of databases. Whatever, it is not that hard to rewrite a mysql grant statement. Everything seemed well except for surprisingly idiotic logic behind SSL installation options: besides Letsencrypt and uploading own certificate, the SSL configuration page offers to install self-signed certificate and use a 'server certificate' without a possibility to disable this nonsense. I could even accept the fact of relying on that very odd Custombuild feature, which for some reason builds all the server software from sources while the same software is available in rpm/apt packages either directly from vendors or community. But I can live with that and get over almost everything else that is not worth mention. But what I can not accept is that creating a new account now takes several minutes opposite to seconds I'd had with crappy cpanel.
 
So I guess a 'CTRL-Z' back to the former CPanel-setup is out of order at this point then? ;)

As for the account creation, I'm sure you're able to enable the debug-mode and see what's holding everything up.
Does the same happen on a fresh test-server with only say, 1, 10 or 100 installed accounts?

I've got about 80 accounts running and I don't experience any delays when creating a new account.

I'm also sure the devs here are open for suggestions to any feedback you can give, but I'm also sure their eagerness to adopt the feedback will depend greatly on the "way it is presented"...
 
So I guess a 'CTRL-Z' back to the former CPanel-setup is out of order at this point then? ;)

As for the account creation, I'm sure you're able to enable the debug-mode and see what's holding everything up.
Does the same happen on a fresh test-server with only say, 1, 10 or 100 installed accounts?

I've got about 80 accounts running and I don't experience any delays when creating a new account.

I'm also sure the devs here are open for suggestions to any feedback you can give, but I'm also sure their eagerness to adopt the feedback will depend greatly on the "way it is presented"...

There is only one thing holding me back from doing ctrl-z - it is insane cpanel's account-based license pricing. I was forced to switch when I received a $14k+ monthly bill (lol). It was easy enough to convert to DA so taking a u-turn would be effortless.

As for me, the debug mode is a kind of open source approach. I expect that commercial software installed on supported OS must have been thouroughly tested so that end-users wouldn't have to do the QA job. Even without tracing it down I perfectly understand what is happening - the DA daemon just tries to fit those thousands users' data into an ugly in-memory array for a reason which was relevant decade ago and has been forgotten since then. The OS ships with standard utilities like useradd, usermod, etc.. perfectly capable of doing similar tasks, so it is definitely a DA design flaw.

I completely agree that I must apologize for being rude in my pevious post. I do apologize.
 
But what I can not accept is that creating a new account now takes several minutes opposite to seconds I'd had with crappy cpanel.
Most likely a custom script in /usr/local/directadmin/scripts/custom or not working (timing out) DNS server in multi-server setup. As mentioned by @BBM https://help.directadmin.com/item.php?id=293 would help to see what's happening.

Regarding other feedback/suggestions - they're welcome.
 
I could even accept the fact of relying on that very odd Custombuild feature, which for some reason builds all the server software from sources while the same software is available in rpm/apt packages either directly from vendors or community.

I forgot to comment this. I don't think it's true :) Try finding PHP 5.6 with OpenSSL 1.1 support, or 5.3 with systemd support. In addition to this:
Code:
phpMyAdmin with logging failed requests (they've included our patches in 4.8+), but what to do before this?
PHP-FPM socket creation under a different user to make sure quota limits don't make service not to start
caching_sha2_password support in PHP 7.3
and much more...

In addition to this - with CustomBuild you can have a new version build the same moment a new version is announced on php.net, for example. Repositories aren't so fast.

I fully agree on installation speed, however - both methods have their pros and cons.
 
Try finding PHP 5.6 with OpenSSL 1.1 support

I actually have it installed on my servers:
Code:
# php-fpm5.6 -v
PHP 5.6.40-15+ubuntu19.10.1+deb.sury.org+1


# php-fpm5.6 -i | grep -i openssl
...
SSL Version => OpenSSL/1.1.1d
...

5.3 with systemd support

Here comes the Custombuild when someone needs to install a software that reached it's EOL 5 years ago.

caching_sha2_password is natively supported in PHP 7.4 so why not just use it? As to this and other questionable features, we - the providers of shared hosting, must not try to fit the unfittable like soldering php5.3 and mysql8.0. We must strognly discourage the use of deprecated software for the sake of users security and admins' peace of mind. You, the software developers, have to do you best in providing us with what we need - not what users need. In their vast majority users do not even know the difference between cgi and fastcgi, php 5 and php 7, mysql 5 and mysql 8. We must provide users with a covenient way to manage their hosting account, not with an exhaustive choice of features whose meaning is not clear even to some providers.
I admit there are rare cases when user requires older software to run a script written 10 years back. In such cases we must be strong enough to say a big no-no and make the user get a VPS (probably with Custombuild installed :) ).

Now back to the problem. I ran DA in debug mode and here is the output with irrelevant data removed:

Code:
/CMD_ACCOUNT_USER
auth.authenticated
Plugin::addHooks: start
Plugin::addHooks: end
Command::doCommand(/CMD_ACCOUNT_USER)
User::create(password, 0) user=testing2
/usr/sbin/groupadd -g 120005 testing2
/usr/sbin/useradd -m -s /bin/false -g testing2 -u 120005 testing2
User testing2 created successfully
Last wrote=0 writing remaining 109 bytes
stat(/home/testing2) returned 0, just after user creation
stat info:
mode: 16832
uid:120005 (testing2)
gid:120005 (testing2)
size:8
atime:1579436509
mtime:1579436511
ctime:1579436511
User::setQuota(10240, inodes=125000, partition='(null)') user=testing2
quota command: /usr/sbin/setquota testing2 10485760 11534336 125000 137500 /home                                                                            
Error with quotas: setquota: Mountpoint (or device) /home not found or has no quota enabled.
setquota: Not all specified mountpoints are using quota.
...
hogging CPU for 10 minutes without any output except for periodic doCommand(/CMD_JSON_LANG)
...
Command::doCommand(/CMD_ACCOUNT_USER) : finished
 
# php-fpm5.6 -v PHP 5.6.40-15+ubuntu19.10.1+deb.sury.org+1

Isn't it Ubuntu 19.10 specific? What about RHEL8?

Here comes the Custombuild when someone needs to install a software that reached it's EOL 5 years ago.

Not exactly. CentOS 7 (systemd based) was released July 7th, 2014. PHP 5.3 became EOL Aug 14th, 2014.

caching_sha2_password is natively supported in PHP 7.4 so why not just use it?

PHP 7.4 is recent (Nov 2019). MySQL Server 8.0 was announced in April 2018. It means no one could use caching_sha2_password with MySQL 8 until Nov 2019 :) In addition to this, if customers need ionCube and caching_sha2_password - ionCube does have no support for PHP 7.4 yet.

Those things are just one of the reasons.

I'm sorry to say this, but debug doesn't have the data needed. May you create a ticket on this or PM me? It'd take just a minute or a few to say what's happening there :)
 
I think it could be related to /usr/local/directadmin/scripts/custom/dns_write_post.sh. Try renaming it temporary and see if that's it.
 
I think you're bullshitting, 9,000 accounts don't cost 14k.

We're migrating to DA in april, we have several one time CP licenses, make us an offer, then you can stay with it...
 
Code:
User::setQuota(10240, inodes=125000, partition='(null)') user=testing2
quota command: /usr/sbin/setquota testing2 10485760 11534336 125000 137500 /home                                                                           
Error with quotas: setquota: Mountpoint (or device) /home not found or has no quota enabled.
setquota: Not all specified mountpoints are using quota.
...
hogging CPU for 10 minutes without any output except for periodic doCommand(/CMD_JSON_LANG)
...
Command::doCommand(/CMD_ACCOUNT_USER) : finished

Why have you not set up quotas? It would not surprise me if that could have the outcome you describe.
 
I think you're bullshitting, 9,000 accounts don't cost 14k.

We're migrating to DA in april, we have several one time CP licenses, make us an offer, then you can stay with it...
I probably wouldn't have started this topic if I had 9000 accounts, but it is all about 90,000 accounts. When I received cpanel license bill I had 70k accounts and they wanted $0.2 per account.
 
Why have you not set up quotas? It would not surprise me if that could have the outcome you describe.
I manage quotas my own way due to file system limitations. I can't see anything quota-related that could influence account creation process to be thrashing CPU for 10 minutes.
 
Ok. You might be the first one using DirectAdmin with that many accounts on one server. I am sure DirectAdmin will find the reason and optimize/fix it for you. My recommendation is to open a ticket at https://tickets.directadmin.com and put "Att John" or "Att Martynas" in the beginning of the subject (Martynas is "smtalk"). And also give them root access to the server. Those two are the persons best able to find and fix the reason for the delay you experience. For this case wich does not seem to be Custombuild related, I would think John is the best man for the job.
 
I already know what the rip-off artists wants, that's why we're migrating on DA!

But really, having 90k accounts on ONE server? What did you smoked? I know it's legel in canada...

We'll gladly sell you one of our "one time cp licenses" (unlimited number of accounts) as we these no longer needs. Send us a PM.....
 
Last edited:
Just moved over to DA from a piece of crap called cpanel. I wrote a custom script that converted 90000 (yes, ninety thousand) accounts in a matter of hours. All accounts are now valid in DA and perfectly usable with site builder and software installer plugins which I have been providing. One-click webmail login is working perfectly well, unlike one-click login to phpMyAdmin -- stupid DA creates mysql grants for single signon user 'da_sso_xxx'@localhost (seemingly hardcoded) regardless of my remote mysql configuration, that makes an user see blank page instead of his desired list of databases. Whatever, it is not that hard to rewrite a mysql grant statement. Everything seemed well except for surprisingly idiotic logic behind SSL installation options: besides Letsencrypt and uploading own certificate, the SSL configuration page offers to install self-signed certificate and use a 'server certificate' without a possibility to disable this nonsense. I could even accept the fact of relying on that very odd Custombuild feature, which for some reason builds all the server software from sources while the same software is available in rpm/apt packages either directly from vendors or community. But I can live with that and get over almost everything else that is not worth mention. But what I can not accept is that creating a new account now takes several minutes opposite to seconds I'd had with crappy cpanel.
I'm happy to help with this. Can you confirm you're referring to a access_host=1.2.3.4 setting in the file:
Code:
/usr/local/directadmin/conf/mysql.conf
where you'd want it to show [email protected]?
Let me know and I'll quickly add that in for you. Might still have it setup both localhost and 1.2.3.4, as DA uses localhost as the "index".. but we'll see how it pans out. If you wish to create a ticket on this, it would aid in some back-and-forth to confirm things are working as you'd like, etc.

John
 
I already know what the rip-off artists wants, that's why we're migrating on DA!

But really, having 90k accounts on ONE server? What did you smoked? I know it's legel in canada...

We'll gladly sell you one of our "one time cp licenses" (unlimited number of accounts) as we these no longer needs. Send us a PM.....
This particular server only hosts the control panel and emails. Actual web hosting happens on several apache backends, distributed file system, and remote mysql server.

I no longer need cpanel too. I have already tried an unlimited offer from HostDime included with lease of their hardware. After 2 months they started to demand $0.1 per account because cpanel had actually been charging them the account-based fee all the time. The unlimited offer was just a promotion in effort to gain new clients and our cooperation suddenly ended with HD's $17k loss over 2 months.
 
Yeah, we're in the same boat.

fuck cp!

We sell all licenses and migrate to DA
 
Back
Top