DirectAdmin v1.648 has been released

+1, we use CloudLinux, we don't use the DirectAdmin PHP selector on those servers.
 
Last edited:
sparek said:
This is just a suggestion...

Is there a market place for 3rd party DirectAdmin themes/skins?

If not... what's the point of having different themes/skins? Why is there a choice to use a particular theme/skin?

If adjustments have to be made depending on which theme/skin you are using, then clearly data isn't being presented to the theme/skin in a way that is universally parseable.

DirectAdmin should just have the one theme/skin and say "This is the way" in terms of panel layout and experience.

I actually can't remember what the theme/skin is or is suppose to be the default one. The default one starts with an E and the other one also starts with an E. If you are running into theme/skin issues and you're using the theme/skin that starts with an E that you aren't suppose to be using - then stop using that theme/skin and switch to the other theme/skin that starts with an E and only use it. Don't like it? Tough.

Unless of course the issues with the theme/skin is the theme/skin that starts with E that you are suppose to be using.

What theme/skin that starts with E are we supposed to be using anyway?
Click to expand...

The skin - Enhanced - existed for many years (may be near/over 20 years). It is running fine, fast, neat, but not responsive in terms of latest web design.

The skin - Evolution - released in these few year(s). It employs modern design (responsive layout).

There are (or were) a few 3rd party DA skins.

Some admin (like me) likes to use Enhanced.
 
The PHP Selector will come in handy for those (including me), that do not use Cloudlinux.
I prefer we have an option for that, including for subdomain.

We need to figure a toggle on/off for that.
 
We do use PHP Selector. However for a complete user. So a toggle to enable/disable the feature for subdomains would be sufficient.

If you don't use PHP Selector at all you can hide in in the menu. Although this probably would still show at subdomains settings.
 
Joriz said:
We do use PHP Selector. However for a complete user. So a toggle to enable/disable the feature for subdomains would be sufficient.

If you don't use PHP Selector at all you can hide in in the menu. Although this probably would still show at subdomains settings.
Click to expand...
I'm not sure if another setting is needed (although I'm not going to say that it isn't either).

But if php_version_selector=0 is set in /usr/local/directadmin/conf/directadmin.conf then the I would argue that the Subdomain feature doesn't need to show a PHP Version column. Although technically, it won't show anything to be changed.

You can get too many settings and they just make things ambiguous. Perhaps there is a reason to have an option, i.e. php_version_selector_control that can be set to either domain (meaning PHP version can be selected on a per domain or subdomain basis) or account (meaning PHP version can be selected by account, i.e the Linux system username). But if php_version_selector=0 then php_version_selector_control would have no meaning.
 
ccto said:
The skin - Enhanced - existed for many years (may be near/over 20 years). It is running fine, fast, neat, but not responsive in terms of latest web design.

The skin - Evolution - released in these few year(s). It employs modern design (responsive layout).

There are (or were) a few 3rd party DA skins.

Some admin (like me) likes to use Enhanced.
Click to expand...

Well, what I'm saying... if the DirectAdmin developers aren't going to integrate Enhanced into this "new" DirectAdmin system they have created... then why is Enhanced even still an option? At whatever DirectAdmin release the decision was made to stop integrating functionality of the DirectAdmin system into Enhanced... why wasn't Enhanced just removed and everything switched over to Evolution?

Enhanced and Evolution are essentially a GUI front-end. The DirectAdmin core is the backend. It would appear that at some point the DirectAdmin core started functioning in a way that Enhanced did not understand. It was at that point that Enhanced should have just been removed.

Obviously the DirectAdmin backend was changed in such a way that backwards compatibility with Enhanced did not work.

If the concept of theme/skin had never been created, then none of us would be any the wiser. We would just have known that at whatever version that backend changed that the interface GUI frontend would change for DirectAdmin.

If there's no support for multiple theme/skin then there's no reason to qualify Enhanced or Evolution as a theme/skin. It would just be "the way that it is."
 
  • Like
Reactions: BBM
[root@myserver custombuild]# ./build versions
Latest version of DirectAdmin: 1.648 build c995cc90e3d5f1c67dd7e9ebb2f7c0fe5d52d585
Installed version of DirectAdmin: 1.648 build c995cc90e3d5f1c67dd7e9ebb2f7c0fe5d52d585

Latest version of Apache: 2.4.57
Installed version of Apache: 2.4.57

Latest version of Nginx: 1.23.3
Installed version of Nginx: 1.23.4

Nginx 1.23.4 to 1.23.3 update is available.

[root@myserver custombuild]# ls custom_versions.txt
ls: cannot access 'custom_versions.txt': No such file or directory
Click to expand...
Any idea why CB shows downgrading for Nginx?
 
gate2vn said:
Any idea why CB shows downgrading for Nginx?
Click to expand...
NGINX 1.23.4 is not yet officially available via custombuild and since you don't have custom_versions.txt you are now requested to download to 1.23.3

Just create a custom_versions.txt with the following content and you should be fine. Just keep in mind that you should keep checking yourself for new updates.

Create a file named custom_versions.txt in /usr/local/directadmin/custombuild
nginx:1.23.4:

It is strange DirectAdmin has not released any new NGINX updates via Custombuild since February, sounds a bit as if they have dropped support on NGINX as both 1.23.4 and 1.24.0 have not appeared into the latest custombuild releases.

@fln / @smtalk :: Did DirectAdmin drop support for NGINX as there are two new versions released after 1.23.3 but not shown in Custombuild ?
 
Last edited:
Joriz said:
We do use PHP Selector. However for a complete user. So a toggle to enable/disable the feature for subdomains would be sufficient.

If you don't use PHP Selector at all you can hide in in the menu. Although this probably would still show at subdomains settings.
Click to expand...
@fln is this a know issue at DirectAdmin? It would be nice if at subdomains the PHP version option can be disabled.
 
A new build c233e241c2805ccf4d4af2432d0d6f82fab6c474 is released with a security update.

@ps4all, we are still testing new nginx builds, nginx 1.23.4 is available on the mirrors so it is available if nginx version is customized. We expect to bump nginx with the DA 1.649 release.

@Joriz a special control knob for PHP selector availability only on sub-domain level sounds like a very niche use-case. Does keeping the option to change PHP version for sub-domains causes any problems?
 
This is an automated message notifying you that DirectAdmin has been successfully updated with warnings.
v1.648 (c995cc9) to v1.648 (c233e24)

Warning message:
/usr/local/directadmin/scripts/update.sh (exit status 1):
Click to expand...

First time I'm seeing this

On all servers by the way
 
Last edited:
Thanks @Erulezz, repacked release with build ID ef029e9290a15af5cfb41b4a72804aeff23c1c25. The message is harmless but we repacked the release to suppress it.

This message is generated when update.sh scipt exits with non-zero exit code. The previous release had a concise bash if clause cmd1 && cmd2. Which when placed at the end of the script reports cmds1 result as the exit code of the whole script. Repackaged update.sh has longer expression if cmd1; then cmd2; fi, which avoids reporting cmd1 status which is used only to check if cmd2 needs to be executed.
 
fln said:
@ps4all, we are still testing new nginx builds, nginx 1.23.4 is available on the mirrors so it is available if nginx version is customized. We expect to bump nginx with the DA 1.649 release.
Click to expand...
Thanks... in the meanwhile NGINX 1.24.0 got into stable (1.23.4 in mainline).
 
There's a bug in CustomBuild when running update_full.

Code: 
./build: line 18272: updateDA: command not found

It's the only mention of updateDA in the CustomBuild script. Perhaps it should be doUpdateDA?
 
  • Like
Reactions: fln
Cloudlinux team adviced me switch to updates from OS pachages with next steps:

Please consider disabling the whole line exclude line in both /etc/yum.conf and /etc/dnf/dnf.conf to proceed with the lsapi update.
To update execute:
yum update liblsapi* --enablerepo=cloudlinux-rollout-3-bypass
cd /usr/local/directadmin/custombuild
./build update
./build set php1_mode lsphp
./build php n
./build apache
---
Is it safe? Webmail/phpmyadmin based on default php will work fine? Currently default php is php-fpm, but websites don't use it, they on cloudlinux selector.
 
You must log in or register to reply here.
Back
Top