DirectAdmin 1.63.2 has been released

And you get it skipped. Am I missing something here? :)
Ah I've overseen that one, sorry. I presume this also skippes the BMF stuff scripts DA uses with CSF on auto install.
It will probably needs some getting used to as you can't select the versions/modes to install etc. from php and mysql and apache during setup.sh execution, but that would be solved by the pre-defined options.conf if needed.
Thank you.
 
Just a quick question, which php version will be installed by default, the newest every time (which is the newest version then) or will this still be a choice during setup?
 
BMF stuff scripts DA uses with CSF on auto install
It doesn't use any, as it has native integration into DA (BFM calls CSF directly).

It will probably needs some getting used to as you can't select the versions/modes to install etc. from php and mysql and apache during setup.sh execution, but that would be solved by the pre-defined options.conf if needed.
pre-defined options.conf isn't so straightforward, while something like the following is (isn't it?):
Code:
export php1_release=8.1
export mysql=8.0
./setup.sh LK

It's documented here: https://docs.directadmin.com/gettin...ning-the-installation-with-predefined-options

Just a quick question, which php version will be installed by default, the newest every time (which is the newest version then) or will this still be a choice during setup?
7.4
 
It doesn't use any, as it has native integration into DA (BFM calls CSF directly).
So this part will only be skipped if I use my custom scripts in the custom directory, like before, right?

pre-defined options.conf isn't so straightforward, while something like the following is (isn't it?):
I wouldn't know, I'm used to just use setup.sh and then get choices I want. Maybe this new system is better and/or more is possible, but as said, it will take some getting used to. Not a big issue.

Yes now..... but this is what I mean. This is now.
But in the future, when will this change to 8.0 (or a newer version) and if it does, how will we know that? Because now it's automatically setup for us?

So suppose in the future we want to be sure some version is setup as default, we have to know some whay which version is used by DA by default, at that time of installation. So we know if we have to change this or not.

Suppose next month it's changed to 8.0, how to we know 8.0 is used by default and we have to use a skip option or user some pre defined setting (same for mysql/mariadb versions)? That was what I meant with my question.

So in short, how will we know which defaults DA will be using during setup time, not at this moment but also in the feature, is there a command to see this? So we can take appropriate action if needed.
 
So this part will only be skipped if I use my custom scripts in the custom directory, like before, right?
I see no point not to install CSF on the installation time, if you're going to install it anyway? :)

I wouldn't know, I'm used to just use setup.sh and then get choices I want. Maybe this new system is better and/or more is possible, but as said, it will take some getting used to. Not a big issue.
It is not a big deal to bring that user-input method back for CustomBuild choices if there's a demand for it. I guess we'll see?

But in the future, when will this change to 8.0 (or a newer version) and if it does, how will we know that? Because now it's automatically setup for us?
It can be changed anytime after the installation, but we may bring some better alternatives for this if needed, as I see your point.

I'd suggest using that "export" methods for the options you'd like to "stick" with. That way it'd always try to use that option.
 
I see no point not to install CSF on the installation time, if you're going to install it anyway? :)
Because I don't want to use the integration between BFM and CSF, I would like to use my own scripts for that. Or will the integration be also automatically disabled when I put these scripts in the custom directory? Because then indeed it wouldn't make a difference.

It is not a big deal to bring that user-input method back for CustomBuild choices if there's a demand for it. I guess we'll see?
Oh that would be very pleasant... let's call some people @ikkeben @Yoshua @bdacus01 I'm curious. Makes life a lot easier then typing command line stuff. :)

It can be changed anytime after the installation, but we may bring some better alternatives for this if needed, as I see your point.
Yes if possible, because changing afterwards would mean extra time/work. I think it might be already enough if there would be some command which shows which default packages would be installed.
 
hi everyone, we have just pushed a hot-fix for the 1.63.2 release. Initial release build ID (commit) was af081e76870b2709b15475ed6ea5fd49548b201f, the hot-fix build is 77d8ed73f9a27ade41e54303ce872bdb06c8cbf0.

The hot-fix release includes two changes:
  • Evolution skin fix for user package management functionality, the issue was present only in servers without pro-pack license.
  • A fix to start suppressing all directadmin.conf related errors in dataskq.
Thanks for reporting the issues.
DA not updating on Debian 10: Current - Default Release Channel

Server Version 1.63.0
Current Available Version 1.63.2000

Got this to the Message system:

*** An error has occurred while trying to update the software ***​

2021-11-30 22:41:04

This is an automated message notifying you that an error has occurred while trying to update the software.
The generated error message is as follows:

Get "https://download-directadmin.nyc3.c...1e54303ce872bdb06c8cbf0_debian10_amd64.tar.gz": dial tcp 205.185.216.10:443: connect: connection refused

Please contact JBMC-Software, including the error message. Failure to do so could result in an inactive control panel.
 
Last edited:
@jet1972, please make sure your server has working internet connection. Download URL seems to be working fine from our end. Or maybe there were some temporary connectivity issues inside the CDN we use for hosting download files.

If the problem still persist we would need a trace route to the download servers. I have provided more details in private conversation message.
 
In two virtual servers installed today we have seen the same problem, using our own CB configuration files and the corresponding exports before executing the "setup.sh", once all the installation is finished, apparently correctly, on the show services page not all services are visible, and yes, they have been installed and are up and running. In one of the VMs that for the client it was urgent we have used a "./build all d" and once finished, all the services are already shown well.

1638318512259.png
 
In two virtual servers installed today we have seen the same problem, using our own CB configuration files and the corresponding exports before executing the "setup.sh", once all the installation is finished, apparently correctly, on the show services page not all services are visible, and yes, they have been installed and are up and running. In one of the VMs that for the client it was urgent we have used a "./build all d" and once finished, all the services are already shown well.

View attachment 4974
It's been fixed in CB 2.0 rev. 2796.
 
I wouldn't know, I'm used to just use setup.sh and then get choices I want. Maybe this new system is better and/or more is possible, but as said, it will take some getting used to. Not a big issue.

Thanks for your kind replies/feedback (as always). Correct, not a huge issue, but it certainly is a convenience/familiarity issue. The user-input will be back in the next stable release (and available in the alpha build shortly).
 
As long as I still have the ability to customize the auto install and not use the csf integration it’s good by me.

If I can’t customize it’s an issue
 
Hi, i don't know if i'm in the right place to report an Evolution skin issue, after upgrading from Directadmin 1.62.9 to 1.63.2 i noticed that in the user list the users near the usage limits and the ones that are overquota, are not highlighted anymore.

I did some checks and have found that in /usr/local/directadmin/data/skins/evolution/assets/css/app.css are missing these lines i've taken from the previous verison:

CSS:
.table-elem.\--overusage-highlight .\--usage\:overused{background-color:var(--danger)!important;color:#fff}
.table-elem.\--overusage-highlight .\--usage\:almost_used{background-color:var(--danger-l60)!important;color:#fff;font-weight:600;color:#34383c}
 
After we updated the server of one of our customers to DirectAdmin 1.63.2, some problems started to occur, apparently maintenance tasks stopped running, like night tally. We checked /var/log/directadmin/errortaskq.log, which was full of this error:

[fatal] directadmin service is not running, refusing to run error=unable to get license info: Get "http://unix/license": dial unix /usr/local/directadmin/da-internal.sock: connect: no such file or directory

DirectAdmin, however, was fully accessible to clients on port 2222.

The problem was fixed by simply restarting DirectAdmin (service directadmin restart).

Maybe there is a bug in the update script, and the DirectAdmin status system itself was not able to detect it, as part of DirectAdmin was running ok.
 
@unihostbrasil, I think the issue was caused by directadmin service not being restarted after upgrade. Because upgrade was done successfully cron was running latest version of dataskq, while directadmin without a restart was running older version.

The issue should not occur anymore since latest directadmin takes care of providing required functionality for dataskq.

We will double check the upgrade scripts. Could you please give us DA version from which you upgraded to DA 1.62.3?
 
@unihostbrasil, I think the issue was caused by directadmin service not being restarted after upgrade. Because upgrade was done successfully cron was running latest version of dataskq, while directadmin without a restart was running older version.

The issue should not occur anymore since latest directadmin takes care of providing required functionality for dataskq.

We will double check the upgrade scripts. Could you please give us DA version from which you upgraded to DA 1.62.3?

Thanks for the quick feedback and for checking the scripts.

The update was from version 1.63.1 (updated on 2021-11-09 12:24) to 1.63.2.
 
Hmm something does not add up yet. directadmin service starting version 1.62.8 always creates da-internal.sock file on start. This file also removed when directadmin service is stopped.

Even older DA should have provided the required services for dataskq.

Error messages hints us that the file was absent in the system. So I think there could have been three scenarios:
  • directadmin service was not running (and removed da-internal.sock on shutdown). Seems unlikely 😄 considering web panel was functioning at that time.
  • A new directadmin service started before old one terminated and old one on termination removed the da-internal.sock which was already owned by a new process. Will do some tests to check this hypothesis.
  • File da-internal.sock was removed by some external tools or actions. Sounds like a long shot.
 
Last edited:
@unihostbrasil, could you give us more details about the OS? Are services managed by systemd or rc scripts?
 
Back
Top