DirectAdmin v1.645 has been released

I also noticed some weird behavior if I configure 2FA via time codes.

What I did/how to reproduce:
1. Add 2FA time code to a DirectAdmin account.
2. Enable "Require valid Two-Step Authentication Code to login to this account." and disable "Allow API logins with the current User/password. Login Keys and Session Keys are always allowed." and click save.
3. After a couple of seconds go to a diffrent page.
4. You will now see the login screen and the login screen gets constantly reloaded. (Clearing the cookies fixes the issue.)

EDIT:
If you click on the logout button directly after saving the new settings (logout directly after step 2) then it will not refresh loop on the login page.
 
@ItsOnlyMe, the idea with integrated CB is that anyone that were not using CustomBuild can continue not use it. The feature will be in DA but there is no need to use it. You can just ignore it.
 
@fln Yes, but the problem for us is that we have customers that get full access ( this without root level access ) to their VPS or dedicated servers as admin user in Directadmin and will run custombuild stuff. This will break software related to Cloudlinux and our setups.

I do not want to give access to such features where they can break things and I get called out of bed at night because stuff broke due to the customer making a change in CB for example change lsphp to php-fpm and run the build. For this exact same reason we are also forcefully deleting the CB plugin dir every time.

So can we get a option to enable or disable this feature?
 
There is a slight problem with rootless DA. DA was never designed to work properly for users having admin account but no root access to the server. Your use case essentially asks for 4 level user role support. User -> Reseller -> Rootless Admin -> Root Admin.

I understand that it kind of worked for you without much changes. But the problem was always there, just not that visible:
  • Any admin account can always get root access (via plug-in system).
  • Any admin account can always mess up DA instance by customizing changing web server configs.
  • There are cases when DA expects admin account to have root access to resolve the issue:
    • firewall (csf) control
    • removing oneself from the DA IP blacklist
    • licensing problems might require DA to be restarted from root
As soon as we say we support rootless admins we are opening up issues described above. The list is not full, just some ideas that comes to my mind quickly.

So using rootless admins is not a feature supported by DA, but rather feature by accident that got used (or abused :)).

We do not want to force CB usage for everyone and we do not want to deliberately break your use case of rootless admins. The best way forward as I see it is to upgrade CB to be less intrusive. But not adding a master CB "kill switch". Instead making sure CB could be disabled on a per-service level. Right now CB has control knobs for optional features (for example clamav, or local MySQL/MariaDB) when feature is turned off it does not suggest you to install or upgrade the service. But some core features are expected to be always wanted (I think DNS server and email server).

More fine grained control on the services managed by CB (and ability to say there are no services that CB should manage) would be beneficial for everyone (not just rootless admin use-case). While it would still be useful for you as well. If you turn off all CB managed features, the CB section will show no updates or suggestions. You could still enable them by changing CB config, but that would not be something you could do by accident (same like messing up config files).

@ItsOnlyMe what do you think?
 
@fln I think we do not fully understand each other.

While I understand the way Directadmin is doing things currently there are a lot of things where I personally disagree with in comparison to previous years and get strongly the feeling that we are being forced to go one route.

I fully understand that there are things that require root access in order to being fixed, like you said if you are being blacklisted. To make more sense of my way of thinking I'll explain a bit what our use-case is.

We are a service provider that do the management of said servers for a customer.
1. Customers buys a VPS or dedicated server from us, including a Directadmin license + Cloudlinux.
2. We install/deploy the server and only give Directadmin login from the admin user to the customer.
3. We do the management of said servers for the customer.
We run a centralized config management system that will set all the correct configs for the server, makes sure certain options are set in Cloudlinux and ensures our scripts are on there so it makes managing the server for us easier.

If a customer has a problem with their server or needs a change to anything, customer contacts us and we make the change if its needed.
All of this time the customer never gets full root access to the server and is only able to login as admin.

Changing web server configs, like you said is a lot less harmfull then having the PHP mode being changed from lsphp to mod_php or php-fpm and run a build for this will break a lot more things. the Cloudlinux PHP selector does not work with mod_php and php-fpm.

Example: We use Cloudlinux and mysql-governor ( cl-MariaDB-10.4 ).
A while back we had a customer that made the change in custombuild to have it install MariaDB 10.6 from the original repositories and ran the build for this, next up we get a ticket from the customer that some things in MySQL are not working correctly anymore. on checking this server we saw cl-MariaDB-10.4 installed and all of its packages + MariaDB-10.6 packages from the normale repo's. You can understand that this will interfere with each other.
Customer blamed us that we broke it all since he had "no root" access. Upon checking the logs we could clearly see that changes where made from within Directadmin.

You could still enable them by chaning CB config, but that would not be something you could do by accident (same like messing up config files).
Click to expand...
When someone is saying this it makes me wonder if they ever worked in such an industry as myself. People / customers like to click, they click on everything they see without reading and knowing any consequences that are coming with doing such things. So yes, they are able to f**k this up by accident in some way. And I want to prevent this from even being a option in the first place. Less hassle for everyone and I can have my well earned night sleep.

Having CB being less intrusive is also a option but wont fit our use-case and I think others on the forum as well. Being able to control whether to see / use this from within Directadmin or not would suit us a lot better.
 
The safety net you expect from GUI in DirectAdmin is at the reseller level. All of DA features for admin is intended for person or company managing the server. In the example you described that would be you, not your client. Would giving reseller level access for your clients work for you? What admin level features do they need?
 
  • Like
Reactions: jca
fln said:
The safety net you expect from GUI in DirectAdmin is at the reseller level. All of DA features for admin is intended for person or company managing the server. In the example you described that would be you, not your client. Would giving reseller level access for your clients work for you? What admin level features do they need?
Click to expand...

This wont work of-course... They buy the server to be able to have access in creating reseller accounts for example. It was never a option to change custombuild options nor build it from inside of Directadmin. It should be a option to choose whether you want it enabled or not.
 
Client with admin access also can look for mail queue, restart services, check server logs or move user beetwen accounts etc. All of this is usable and harmless.
I also think that custombuild plugin in control panel should have option to disable.
 
It is possible to make new CustomBuild integration non functional by adding custombuild to the never_commands list in directadmin.conf:

Code: 
# da config-set never_commands custombuild --restart
never_commands=custombuild

The menu entry would still be visible but any CB related action would not work. We could make UI improvement to hide the CustomBuild from menu when we detect that command is blacklisted.
 
If the menu is still visible is not a problem. Users being able to build stuff is really a no-go, so this would work.

Another thing is Single files.directadmin.com download , why? Since we provision a lot of servers with Directadmin, how are we still able to use our own internal mirror for installations and updates.
 
ItsOnlyMe said:
Since we provision a lot of servers with Directadmin, how are we still able to use our own internal mirror for installations and updates.
Click to expand...

This is a fair comment. But honestly, how many people use this feature to justify DirectAdmin spending development resources building this?

Let's say you have 100+ DirectAdmin servers performing an update; by using your own internal server, you might save a couple of GB of bandwidth.

I would rather DA spend its resources to build a reliable CDN that benefits all users.
 
ItsOnlyMe said:
If the menu is still visible is not a problem.
Click to expand...
If custombuild is disabled as command menu item is visible (but non functional) in DA 1.645 (stable) and hidden in DA 1.646 (current).

ItsOnlyMe said:
Another thing is Single files.directadmin.com download , why?
Click to expand...
We are using CloudFlare CDN for distributing contents of files.directadmin.com. You no longer need to run your own internal mirror. Files will be cached at CloudFlare edge node near your servers, so download speed will not be an issue. Amount of CF edge nodes is much greater than old DA mirrors.

1674479096270.png

CustomBuild no longer supports setting up custom files mirror via config file.
 
We also have the issue with the suexec patch. All websites in error 500
Code: 
[root@s1 custombuild]# suexec -V
 -D AP_DOC_ROOT="/"
 -D AP_GID_MIN=100
 -D AP_HTTPD_USER="apache"
 -D AP_LOG_EXEC="/var/log/httpd/suexec_log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_PER_DIR="yes"
 -D AP_UID_MIN=100
 -D AP_USERDIR_SUFFIX="public_html"

did build update / build clean / build all / build rewrite_conf
same issue.

In the custombuidl logs I have lines rferring to patching of suexec.
Updating to 1.646 and building apache, hopefully it will fix the issue.
 
fln said:
We are releasing new DA 1.645 build c52eab63c147d7c6ca97405d0b87272465465d20, it addresses the following issues:
  • CB fix for Apache + PHP suexec, thanks @brandyou
  • Backup upload via FTPS fix for Ubuntu 18, thanks @ZipperZapper
  • Couple of regressions in Evolution File Manager - showing English instead of custom language, tree directory expansion refresh loop
Click to expand...
Can we have more details about the point :
  • CB fix for Apache + PHP suexec, thanks @brandyou

    what was changed and where ?
 
@netswitch, file custombuild/patches/suexec-safe.patch used to patch Apache configure.in file to add support for --with-suexec-safedir parameter. CustomBuild in DA 1.645 no longer uses autoconf tools to recreate the configure script so patching configure.in does not change anything.

In the hot-fix released with c52eab63c147d7c6ca97405d0b87272465465d20 patch custombuild/patches/suexec-safe.patch was updated to patch the sources directly instead of patching configure.in which was used to generate configure script in older CB versions.
 
Ok, many thanks for thes details, I will check on the machine that would not work if we had the right patches.
 
Currently experiencing the same sftp / ftps issue on proftp. Fix #2 has been applied from https://help.poralix.com/articles/proftpd-cannot-support-both-ftps-and-sftp-for-the-same-host. Except now getting
1675193159704-png.6451
 
You must log in or register to reply here.
Back
Top