DirectAdmin 1.678

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,152
We are happy to announce the release of DirectAdmin 1.678.

This release gets a new feature for executing system package updates in DirectAdmin UI. The available system updates will be reported in the same way as CustomBuild updates - the update count bubble in the menu. Second new feature is the addition of buypass.com as a new ACME provider.

A full release change log is here:

DirectAdmin 1.678​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
fln said:
This release gets a new feature for executing system package updates in DirectAdmin UI. The available system updates will be reported in the same way as CustomBuild updates - the update count bubble in the menu. Second new feature is the addition of buypass.com as a new ACME provider.
Click to expand...

Thank you so MUCH
 
fln said:
This release gets a new feature for executing system package updates in DirectAdmin UI.
Click to expand...
I thought I saw this discussed somewhere, but can't find it again. I would very much like to disable this. I would also like to disable custombuild updates. The reason is that we manage servers for people, but they still have admin access in DA for various reasons. Typically we tell them "don't touch any updates, or else!", but it would be really nice to just not have it available to them in the first place.

Any way to do that?
 
@kristian, these features can be disabled with the never_commands option:

Code: 
da config-set never_commands custombuild:system-packages --restart

This makes them not only hidden from the UI but also non functional via API. Demo:

Code: 
# curl $(da api-url)/api/system-packages/updates
{"packages":[]}

# da config-set never_commands custombuild:system-packages --restart

# curl $(da api-url)/api/system-packages/updates
{"type":"ACCESS_DENIED"}


The system packages page should be relatively safe even for non tech-savy users. It does not allow installing new packages or removing existing packages (except when this is a side effect of a package upgrade).
 
Last edited:
As a regular DirectAdmin user, I personally believe that the system update feature should be available to everyone — including those with legacy licenses. It’s a very convenient function, and it’s worth noting that it was already present in your panel over a year ago. Making it exclusive now feels like taking a step back in terms of usability and support.
 
You guys are some whiners. Get over it, DirectAdmin is not even that expensive, is well developed and is only getting better. Just get a decent license and you're done.
 
exlhost said:
You guys are some whiners. Get over it, DirectAdmin is not even that expensive, is well developed and is only getting better. Just get a decent license and you're done.
Click to expand...


It’s not a matter of money—it’s about the fact that these were features I personally appreciated years ago, when I was sold a lifetime license.

If it’s no longer lifetime, that’s absolutely not my fault, and I would have liked to have that feature back.

Of course, as soon as I outgrow it, I’ll switch to a subscription to get the new MariaDB. But for now, for my five domains on a small cloud, I’ll make do with the lifetime version.
 
Last edited:
We understand this is not great from the legacy license owner's perspective. The general policy is that we make new features for modern licences only. I would like to clarify that DirectAdmin did not have a system packages management feature before.

For a while, the CustomBuild script used to report if it noticed any system package updates, but the whole implementation was just a one-line script, roughly equivalent to apt list ... | wc -l. Because it was so trivial, it led to a lot of problems:
  • Listing CustomBuild upgrades would take very long, because on RHEL systems it might trigger package cache updates over the network.
  • It was not reliable if there were any stray output reported from the apt of dnf tools.
  • It used to cause a nasty deadlock situation if a system package update would call CustomBuild as part of the reconfiguration process. This happened a couple of times with CloudLinux packages.
  • It was reporting false positives when some packages could be removed (Debian systems sometimes report that old kernel packages can be removed).
Because of all that and some more, we just deprecated and removed this feature. The full original code of the removed feature is 😄:

Code: 
-       local distro_updates=0
-       if distro_is_debian; then
-               distro_updates=$(apt list --upgradable 2> /dev/null | grep -c 'upgradable from:')
-       fi
-       if distro_is_rhel; then
-               distro_updates=$(yum --quiet --assumeno --cacheonly list updates | grep -c -v -e '^Updated Packages' -e '^Available Upgrades')
-       fi
-       if [ "${distro_updates}" -gt 0 ]; then
-               dump_version_line "${SYSTEM_PACKAGES_COMPONENT}" "update_system" "" "${distro_updates} upgradable packages" "command_update_system"
-       fi

If anyone still misses that feature, it can be recreated by using this command to check for updates da build versions && echo "There are $(apt list --upgradable 2> /dev/null | grep -c 'upgradable from:') system package updates".
Now the new feature is much, much more powerful. It is implemented in the main DirectAdmin service. The package management system is aware of what packages are available for update (from which version to which version). Prior to the execution of a package upgrade, it can consult with system package management software and show you accurately which additional packages will be installed as dependencies or what additional packages will be removed because they conflict with new software.

However, in my personal opinion, the best part is the package update history. The package management system can extract information about the previous interactions with the APT/DNF system. Even if you are not using DA to perform system updates and perform all package management operations from CLI, the history section will show you all the logs with information about what package management operations were performed, which packages were affected and even allow you to check the package installation log. Very useful if there were some warnings, but the terminal on which the update was performed is already closed.

The existing feature structure also allows us to easily extend it in the future if we want to support more system package management operations. For example - show all system config files that need to be checked after a system update (the ....dpkg-dist, ...dpkg-old, etc. on Debian systems, or ...rpmnew on RHEL systems).
I think it is not fair to say that this feature used to exist in the panel before.
 
fln said:
We understand this is not great from the legacy license owner's perspective. The general policy is that we make new features for modern licences only. I would like to clarify that DirectAdmin did not have a system packages management feature before.

For a while, the CustomBuild script used to report if it noticed any system package updates, but the whole implementation was just a one-line script, roughly equivalent to apt list ... | wc -l. Because it was so trivial, it led to a lot of problems:
  • Listing CustomBuild upgrades would take very long, because on RHEL systems it might trigger package cache updates over the network.
  • It was not reliable if there were any stray output reported from the apt of dnf tools.
  • It used to cause a nasty deadlock situation if a system package update would call CustomBuild as part of the reconfiguration process. This happened a couple of times with CloudLinux packages.
  • It was reporting false positives when some packages could be removed (Debian systems sometimes report that old kernel packages can be removed).
Because of all that and some more, we just deprecated and removed this feature. The full original code of the removed feature is 😄:

Code: 
-       local distro_updates=0
-       if distro_is_debian; then
-               distro_updates=$(apt list --upgradable 2> /dev/null | grep -c 'upgradable from:')
-       fi
-       if distro_is_rhel; then
-               distro_updates=$(yum --quiet --assumeno --cacheonly list updates | grep -c -v -e '^Updated Packages' -e '^Available Upgrades')
-       fi
-       if [ "${distro_updates}" -gt 0 ]; then
-               dump_version_line "${SYSTEM_PACKAGES_COMPONENT}" "update_system" "" "${distro_updates} upgradable packages" "command_update_system"
-       fi

If anyone still misses that feature, it can be recreated by using this command to check for updates da build versions && echo "There are $(apt list --upgradable 2> /dev/null | grep -c 'upgradable from:') system package updates".
Now the new feature is much, much more powerful. It is implemented in the main DirectAdmin service. The package management system is aware of what packages are available for update (from which version to which version). Prior to the execution of a package upgrade, it can consult with system package management software and show you accurately which additional packages will be installed as dependencies or what additional packages will be removed because they conflict with new software.

However, in my personal opinion, the best part is the package update history. The package management system can extract information about the previous interactions with the APT/DNF system. Even if you are not using DA to perform system updates and perform all package management operations from CLI, the history section will show you all the logs with information about what package management operations were performed, which packages were affected and even allow you to check the package installation log. Very useful if there were some warnings, but the terminal on which the update was performed is already closed.

The existing feature structure also allows us to easily extend it in the future if we want to support more system package management operations. For example - show all system config files that need to be checked after a system update (the ....dpkg-dist, ...dpkg-old, etc. on Debian systems, or ...rpmnew on RHEL systems).
I think it is not fair to say that this feature used to exist in the panel before.
Click to expand...
I understand and fully agree with everything you explained.

For now, I’ll continue doing the usual updates manually via SSH.

Your new system is definitely impressive — I had a chance to test it with the alpha version a couple of days ago, and even with my legacy license, it worked beautifully.

It’s a pity I can’t use it at the moment, but I’ll definitely consider upgrading my license in the future. 😊
 
Yes. During DA update customised Dovecot 2.3 files will be automatically moved into 2.3 sub-directory to follow the layout change of main CustomBuild config files. No extra action from the server administrator is needed.
 
fln said:
Yes. During DA update customised Dovecot 2.3 files will be automatically moved into 2.3 sub-directory to follow the layout change of main CustomBuild config files. No extra action from the server administrator is needed.
Click to expand...
Except for updating ansible roles to match. Which is why it should be in the changelog. ;) Thanks for confirmation!
 
  • Like
Reactions: fln
You must log in or register to reply here.
Back
Top