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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@sparek netflix run on FreeBSD https://archive.fosdem.org/2019/schedule/event/netflix_freebsd/
Well, I meant using FreeBSD in the context of DirectAdmin.
I'm sure there are people running DirectAdmin on FreeBSD... but how many?
The same thing with Debian... I'm sure there are (probably more than FreeBSD, but I'm just guessing). But at what point does appeasing to fringe users become a detriment?
If 10% of DirectAdmin servers are Debian and 5% are FreeBSD, that means 85% is RHEL/CentOS... doesn't it make more sense to focus your attention to that 85%?
Look... I agree, it's a slippery slope. DirectAdmin has been around for years and to just suddenly stopping support for things they have covered for years... that's just not right (FWIW - I'm not really suggesting that they do stop support for those systems).
But... DirectAdmin has suddenly found itself in the limelight after the cPanel fiasco. Does DirectAdmin want to grab this limelight by the horns and run with it or do they want to remain focused on the market they had before the cPanel fiasco? Support for packaged binaries and focusing more on a single distribution (whatever that distro might be... if they want it to be Debian, that's fine too ... I'm also not suggesting that they drop support for other distributions, but being able to focus on one distro is a way to aide coverage for new converts) is one way to move forward. Or if they want to keep their focus on the market they have built up over the years, that's fine too. I'm not telling them what to do. I'm just saying that IF they want to run with this limelight they have found themselves in, then this is one suggestion I would have.
Also, for what it's worth. The Remi repository had PHP 7.1.31 available on their repository before DirectAdmin had it on their mirrors - I remember looking at this when it was released on August 1st. Actually php.net didn't even have PHP 7.1.31 listed and Remi had PHP 7.1.31 listed as an update. But your point is valid. Generally compiling from source is going to get you updates faster. This is part of the cost with everything you do. If you have 50 heavily loaded shared web hosting servers and php.net releases an update. You have a choice. Compile PHP from source on all 50 servers - for argument's sake we'll say that takes an hour to do on each server and adds a little bit of load to the server while it's compiling, OR do you wait 24 hours or so for a package binary repository to release updated packages which takes maybe a minute to install on all 50 servers? How significant is it that you get the updates in that PHP source immediately? How does that weigh in relation to compile time and additional server load?
Again this perhaps points to what DirectAdmin's market was prior to this cPanel fiasco. Maybe DirectAdmin wasn't used that heavily on production shared hosting servers, so compile time and compile load wasn't an issue? Where does DirectAdmin want to be in relation to this?
Further to all of this... compiling is always an option. Even on cPanel servers. If there's something specific I want in PHP that their PHP packages or the Remi packages don't do? I can compile my own PHP on cPanel servers. The reliance on CustomBuild or EasyApache to provide PHP on a server shouldn't be the end-all.
I hope this post isn't viewed as being argumentative. That's not my intention. I really am trying to keep an open mind here. This thread was just made to bring up suggestions on how to improve DirectAdmin. This is one of my suggestions.
Yeah I side on DA's method myself and it's what I do with my own LEMP stack - Nginx and PHP-FPM are source compiled but everything else is mainly YUM/RPM either from repos or my own build custom RPMs and the main motivation is speed of access to updates (less delay between announcement and end user availability - especially if you're at the mercy of slow repository mirror populating of updated packages). FYI, PHP.net since they moved to CDN mirror system usually has new php releases a few days before listing on php.net if you check (I do) as I also follow Remi PHP for it's backported PHP EOL security patches which I use for my own PHP-FPM builds. So if your source compile routines allow for it, you technically can build newest PHP versions before they even get announced on php.net i.e. follow their php-src github release page via RSS subscription
Not sure if it's same motivation for DA, but for me another set of reasons I compile Nginx and PHP-FPM is
Flexibility to apply patches or backport fixes that haven't yet been officially released. Example PHP 7.3.4-7.3.5 had a mysqldnd related segfault issue causing some web apps like Invision board forums to crash and have high cpu load. PHP fixed it but made it only available in PHP 7.3.7, so even PHP 7.3.6 which was due in a few days didn't have the fix. PHP 7.3.7 wasn't due for another 4-6 weeks IIRC. So rather than wait 4-6 weeks, I just backported the fix from yet to be released 7.3.7 to 7.3.4-7.3.6 versions just by feeding in the patch into compile routines and end users get fixed PHP versions without waiting on YUM availability. Of course you can also build your own RPMs with patches but that relates to my 2nd point.
The leg work moves from developer maintaining RPM and build system to just the end user who is in control of when/how fast they run and compile Nginx/PHP-FPM versions. This is freeing up alot of work/effort from developer end as I wouldn't need to maintain YUM repo/RPMs. Pretty sure staff numbers wise, cPanel has way more staff bandwidth to maintain such than DA right now.
Who updates many servers one at a time though ? Much easier to do that in batches simultaneously - i.e. all 50 servers at same time would take the same 60 minutes.
True having both would be ideal situation. I can see DA eventually moving in that direction
One intermediate solution I do in my Centmin Mod latest beta is have feature to be able to backup and restore Nginx and PHP-FPM binaries. So if you compile a new Nginx/PHP-FPM version and it breaks something, you can easily restore to a previous working binary without having to recompile/downgrade. I added this so I also test different binaries with different supported GCC 4.8/7/8/9 and Clang 3.4/4/5/6/7 versions and Profile Guided Optimised binaries etc for performance benchmark comparison testing without having to always recompile. This method can also be used so you can have 2 identical spec servers for one staging and one production, so you can compile the binaries on staging and back them up and restore them and transfer them on production without needing to recompile
Sort of binaries without RPM/YUM LOL.
Maybe DA could have such for a stop gap measure for now ?
@sparek Everything you said was spot-on. Informative, not argumentative.
The reply by @eva2000 shows this -- lots of information, and informed opinions on all sides. This is how it should be.
Regarding installation/compiling times, never heard much grumbling about it from our old customer base -- but we are now being exposed to companies that deploy on mass scales, so it is much more cumbersome for them compared to someone who installs DA once in a while and doesn't even care about compiling time. Obviously we have to give attention to this because it's requested by many. It's not a trivial feature request. You also make a good point about 50 hours of compiling time vs 50 minutes. In larger scale operations, efficiency ranks right up there with security.
Regarding supported operating systems. CentOS and Debian/Ubuntu for sure. We have a surprising amount of licenses set to Debian/Ubuntu so there are no plans for dropping it. As for FreeBSD, I think we are the only ones who support it and it does make up a very small % of all licenses, so at this point it is a fringe OS at least for hosting. I'm not announcing we are dropping it, but if there was one we had to drop, that would be it. At the moment it's not causing us too much extra work to support.
I agree with the precompiled binary. I like DA. When I tried to play with DA, It is a little annoying to compile every time I change small thing to try. Maybe set automation to compile from sources until become rpm or Deb, and also automate the test process. Good automation process should not to change a lot between different software version.
To be honest when I installing DA, my experience so far with 2GB RAM vps are:
I still don't know what's wrong with my installation process
If they have binary version, I can reinstall anything faster. But of course compiling version is good for people that need more customization
Huge difference in how you can optimise first time compile versus recompile of same versions after making changes. On recompiles utilise cccache compiler caching for up to 70-80% faster recompile times for DirectAdmin custombuild routines - benchmarks I posted at https://servermanager.guide/162/how-to-install-directadmin-control-panel-on-centos-7/#step14
@sparek to be fair I use cloud linux php but I like everything else to be compiled as the option for versions ...
Even with cPanel till last year I was compiling easy apache for more than 13 years
So maybe I'm more used to it and I believe compiled for the server/vm is faster than the prebuild but maybe I'm getting old
I got pretty simple routine from the time I has close 30 servers to manage (no all mine) similar to what eva2000 mention
I use test VM on which I do the update first and if it went clear then as I use standardized software setups I push the update on multiple servers simultaneously it will cut the time from 50 hours to
1 hour + time to start in on all 50 servers if do not use something as Puppet
P.S Only the inital DA install is long
Last apache / nginx updates took only couple of minutes per server /vm on not so powefull setups
P.S.S I suggest to do yum install ccache if you recompilig a lot of things
I do not measure the time with it but my stats shows (I do some minor tweaking on that vm related to) I think I'll get better results in time ...
ccache -s
....
cache hit (direct) 2645
cache hit (preprocessed) 177
cache miss 9714
cache hit rate 22.51 %
@DA_Mark keep the FreeBSD if it is not too hard it make you special
it is you and Virtualmin but you are more feature rich ... SO You can claim that you make The Best Control Panel for FreeBSD 
Which can be good for marketing 
if you want the title 
I think open lite speed and litespeed is precompiled for linux from Litespeed not from DA so you are just installing it from custombuild for the integration and config files it is the same as yum installed
@DA_Mark quick question, if i buy owned license and i won't renew support for it after a year do i lose only ability to update direct admin itself (rise version) or do I lose the ability to update components thru custom build as well?
Already discussing it internally. Right now you can use our search bar to find any user or domain, but I'm assuming what you mean is just more easy/efficient switching between users?
P.S. Webmail/phpmyadmin SSO coming soon as requested.
Just DA itself, but this is exactly why we decided against the Owned license going forward. It gives the ability (and incentive) to save money by not updating and that's a recipe for disaster.
Exactly.
Francisco
Noted. Coding for the webmail/php SSO is happening this very moment so let us push that out first. It's an even bigger convenience feature so we really want to get that out.
Nice! Loving it.
Btw, still havent figured out how to enable cronjobs to be setup in the GUI. Care to enlight? 😁
You need to switch over to the User level to see the cronjobs GUI feature, but it should be there.
Here's a 3rd-party guide based on our old skin, but it still applies:
https://www.interserver.net/tips/kb/manage-cron-jobs-in-direct-admin/
Or if I totally misunderstood your question, can you please clarify?
I think it would be a good idea that when you click on the username in directadmin 'show all users' it just opens a new window with you logged in as that user in that new window.
DirectAdmin deffo needs to make custom build a bit better... having to make changes, then re build is a pain.
I don't think it's even showing up on User level, need to check further tho. :P
For yourself (admin) or for a different user? It is an on/off feature in case you don't want shared hosting users to create crons. So it very well could be legitimately hidden. Edit the user in question and see if cron is turned off.
Different user. We did enable the crons :P. I haven't had time to dig this properly yet. Will do so.
I hope DA would not become as arrogant and irresponsible as cpanel in future . The problem is that when people keep praising a product the price goes up
Create more video tutorial for new skin
@DA_Mark I'd really like a way to do an administrative suspend of an email address, or a whole accounts ability to send emails.
In cPanel we have
whampi1 suspend_outgoing_email user=$usernamewhich is helpful when you have a user that has a compromised mail box.Francisco
Maybe not as eloquent as cPanel's solution, but you can always just change the password for the email user in the file:
/etc/virtual/%domain%/passwdSave the hash so you can change it back if necessary.
Be sure to clear the dovecot cache so that the old password isn't still recognized
/usr/bin/doveadm auth cache flushThis will also prevent the user from checking their email. Again, maybe not quite as eloquent of a solution as cPanel's... but cPanel's email suspension works by checking a list in the exim configuration. For DirectAdmin to do this, they will have to do something similar and modify the exim configuration. Changing the email account's password avoids all of this.
Random extra feature request: the DirectAdmin login page doesn't seem to be compatible with Firefox's automatic password saving/remembering feature. It would be great if it was.
Latest release (pre-release) is, stable 1.58.2 with the fix is coming shortly as well
https://help.directadmin.com/item.php?id=655
If you want to block just a global system path (php mail()), you can just use /etc/exim.blockcracking/script.denied_paths.txt for it, for example:
^./wp-content/cache.
^./wp-content/uploads.
To block an email account until he changes his password (button would appear in GUI):
/var/spool/exim/blocked_authenticated_users
To block just a single PHP path:
/var/spool/exim/blocked_script_paths
How aboot rspamd/SA? Or doesn't matter?
Francisco
rspamd/SA are for inbound email, the blocking is for outbound ones. Would you just like to suspend email account from accessing it without ability to 'unblock' it, so that it wouldn't receive any new emails as well?
Nope, what you just described in the 1st half works for me
Thanks boss.
Francisco
And the other DA pain point I've just discovered:
The LetsEncrypt SSL certificate integration shows all hostnames the account could possibly have associated with it - (all prefixes, dot all domains)
But you have to go through each domain associated with your account (using the domain selector in the top right hand corner of the UI) to generate a cert for that domain. If you generate one big cert for all the domains, with a whole heap of subject alternate names ... it only applies to the domain you had selected in the UI when you created it.
So my account has one.com, two.com, three.com
With domain selector (drop down, top right hand corner of DA UI) at one.com I go to create a letsencrypt cert
I add all the names - ftp.one.com, www.one.com, ftp.two.com, www.two.com, ftp.three.com, www.three.com
Cert creates successfully
Then you go to https://www.one.com/ and it all works
but https://www.two.com/ and https://www.three.com/ come back with the wrong certificate and my browser displays its lovely security warning error.
Suggested behaviour: don't show hostnames in the letsencrypt cert creator, other than for the currently selected domain.