DirectAdmin v1.646 has been released

Would be great if anyone affected by this evolution error would share the contents of options-v1.json file. This would help us find out what kind of configuration could cause such an issue. Would be best to send it as a private message. Thanks.
In my case it contained;

{
"defaultLayout": "standard",
"forceLayoutForUsers": true,
"theme": ""
}
 
Did DirectAdmin push out this 1.646 update to servers that have autoupdate=0 ?

Trying to figure out why my servers updated to 1.646 without my explicit command.
 
So apparently

/usr/local/directadmin/custombuild/build update

Does a DirectAdmin update now.

Did I miss the memo on this?

Of course, /usr/local/directadmin/custombuild/build update is utterly useless now since you can't update anything with CustomBuild without first updating DirectAdmin.

But still - for backwards compatibility, /usr/local/directadmin/custombuild/build update shouldn't perform a DirectAdmin update - at least that's my opinion. I'm sure nobody will agree with me.
 
@sparek, this update is no different from the previous ones, if you have autoupdate=0 it will not auto update.

New DA releases provides a way to push-out updates for CustomBuild, that is why ./build update updates DA. I am not a big fan of this behaviour as well and would rather make ./build update a no-op, but this would break expected way of updating CustomBuild. After long internal debate we decided to make ./build update update DA.
 
Like I said, I figured nobody would agree with me.

For anyone wondering, no DirectAdmin did not auto update. I just foolishly left a script running that did a /usr/local/directadmin/custombuild/build update (which was suppose to check for CustomBuild updates).

I'll go on record - and will probably always go on record until this gets changed - but the decision to tie CustomBuild updates with DirectAdmin update was utterly stupid.
 
Originally, /usr/local/directadmin/custombuild/build update was meant to grab a new list of DirectAdmin maintained applications and their DirectAdmin supplied version numbers for CustomBuild.

Used in conjunction with /usr/local/directadmin/custombuild/build versions to show DirectAdmin maintained applications and their versions. Simply running /usr/local/directadmin/custombuild/build versions may or may not have showed the latest DirectAdmin supplied versions (applications that had updates available). Running /usr/local/directadmin/custombuild/build update and then /usr/local/directadmin/custombuild/build versions would serve to update the available application version updates and show what updates were available.

But in DirectAdmin's infinite wisdom to do away with separate application updates and requiring all of that to be in a DirectAdmin update - /usr/local/directadmin/custombuild/build update served to be useless. Except, they also decided that "people that run /usr/local/directadmin/custombuild/build update are probably wanting an application update list... so let's sneak in a DirectAdmin update with that so that the application list will also update."

Like I said, entirely not a fan of this whole CustomBuild application and DirectAdmin update decision.
 
@sparek, this update is no different from the previous ones, if you have autoupdate=0 it will not auto update.

New DA releases provides a way to push-out updates for CustomBuild, that is why ./build update updates DA. I am not a big fan of this behaviour as well and would rather make ./build update a no-op, but this would break expected way of updating CustomBuild. After long internal debate we decided to make ./build update update DA.
custombuild MUST honor the autoupdate value of directadmin.conf, for example, with this update of DA the admin login get locked at:



Captura de pantalla 2023-01-06 a la(s) 00.44.13.png

So to avoid problems I set the autoupdate to 0, but as custombuild wont honor this value, after a ./build update, DA was updated and the problems start.

[root@da ~]# da config | grep autoupda
autoupdate=0
[root@da ~]#

But....

[root@da ~]# /usr/local/directadmin/custombuild/build update
updating to directadmin current v1.646 02a9d50d12fd29395c87d1116d37f189c70a570b linux_amd64

So, after that, just downgrade DA manually:

da update c52eab63c147d7c6ca97405d0b87272465465d20

I'm totally agreed with @sparek and when you said "After long internal debate", may be needed to be a little longer or customer centric.
 
1672981747927.png
In the "system information" tab, I see that mysql is not working. However, after checking it works fine. In the "service monitor" tab it says it's working.


1672981966456.png

The menu is totally gone. There are things in the tabs that shouldn't be there. Any attempt to change the menu has no effect
 
thanks for report @djcart, could you please send me the contents of /usr/local/directadmin/data/users/admin/skin_customizations/evolution/files/ directory, files menu-v2.json and menu-v1.json in a private message? Thanks.
 
Totally agree, DA don't listen to their users (anymore) but just changing the CS behavior without consulting the users.
DA please go back like it was before with CustomBuild we are used to
This....... I know things evolve but the reason I chose DA over any other is that you had more control......
 
@Active8 Agree on that... the time where the customer was #1 seems to be gone.


An update to Evolution is released into current (build ID 2435c493e6fc62a870f78f3b9dcf56e26195c5c8) to fix options config migration issue. Thanks @dmtinc, @dwight_d, @ps4all.
How about the exim_conf issue @fln ?
Already found 5 Debian 10 servers having the mentioned issue, where Exim doesn't start at all due to the error in exim.conf.
 
@ps4all, regarding the exim issue - please make sure you are using the latest exim config. You can regenerate it with ./build exim_conf.
 
@fln and what about:
wget https://download.directadmin.com/setup.sh
chmod +x setup.sh
export DA_INTERACTIVE_CUSTOMBUILD=yes
without exporting to use stable channel - it didn't work anymore, it autoinstalled, why it didn't use just current channel by default as earlier and give me choices what to install?
 
@Zhenyapan, this was regression in 1.645, it is fixed in 1.646 installing 1.646 (current) with DA_INTERACTIVE_CUSTOMBUILD=yes should prompt you for CB config options.

Example:
Code:
root@486a1f9bce4c:/# ./setup.sh {...LK...}
Installing dependencies...
...
[setup.sh] Using these parameters for the installation:
                License Key: {...LK...}
                 DA_CHANNEL: current
                   DA_EMAIL:
             DA_ADMIN_USER :
         DA_ADMIN_PASSWORD :
                DA_HOSTNAME:
                 DA_ETH_DEV:
                     DA_NS1:
                     DA_NS2:
            DA_SKIP_FASTEST: no
                DA_SKIP_CSF: no
      DA_SKIP_MYSQL_INSTALL: no
         DA_SKIP_SECURE_PHP: no
        DA_SKIP_CUSTOMBUILD: no
 DA_INTERACTIVE_CUSTOMBUILD: yes
  DA_FOREGROUND_CUSTOMBUILD: no
...
DirectAdmin should be accessible now
If you cannot connect to the login URL, then it is likely that a firewall is blocking port 2222. Please see:
  https://docs.directadmin.com/directadmin/general-usage/troubleshooting-da-service.html#cannot-connect-to-da-on-port-2222
Would you like to backup the current options.conf? (yes/no, default: yes):

Would you like the default settings of apache and php 8.1 as php-fpm? (yes/no, default: yes):
...
 
Originally, /usr/local/directadmin/custombuild/build update was meant to grab a new list of DirectAdmin maintained applications and their DirectAdmin supplied version numbers for CustomBuild.

Used in conjunction with /usr/local/directadmin/custombuild/build versions to show DirectAdmin maintained applications and their versions.
I use this combo as well in a cron script to check for new updates, and feed it back to a monitoring system so I can be alerted when there are new updates available.

I'm not a huge fan of this combo actually performing an update, but it's not the end of the world for me either. Perhaps we can get a new true no-op build option that will only check for new versions of installed software?
 
I have another issue related to exim.variables.conf.custom.

Some hosts we manage still have pophosts enabled in exim.variables.conf.custom:
Code:
hostlist relay_hosts=net-lsearch;/etc/virtual/pophosts
After the update this file no longer exists:
Code:
ls -la /etc/virtual/pophosts
ls: cannot access '/etc/virtual/pophosts': No such file or directory
The Exim mainlog contains these failures
Code:
2023-01-06 13:33:35 failed to open /etc/virtual/pophosts for linear search: No such file or directory
Exim will still start without the file but no longer accepts incoming mail:
Code:
tom@srv ~ % telnet mail.example.com 25
Connected to mail.example.com.
Escape character is '^]'.
220 mail.example.com ESMTP Exim 4.96-58-g4e9ed49f8 Fri, 06 Jan 2023 13:33:31 +0100
ehlo foobar.whatever.xyz
250-mail.example.com Hello foobar.whatever.xyz [masked]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-PIPECONNECT
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
mail from: [email protected]
421 Unexpected failure, please try later
 
Back
Top