DirectAdmin v1.646 has been released

[fln]

@tomputer, please remove hostlist relay_hosts line from exim.variables.conf.custom. This is not used in our Exim configs for quite a while now. Using pophosts feature should be treated as security issue. It allows unauthorized SMTP access for any IP which recently connected to the server using POP protocol.

 

[tomputer]

@tomputer, please remove hostlist relay_hosts line from exim.variables.conf.custom. This is not used in our Exim configs for quite a while now. Using pophosts feature should be treated as security issue. It allows unauthorized SMTP access for any IP which recently connected to the server using POP protocol.

I'm aware what it does. It was an accepted risk for legacy clients/devices which were (or are) unable to use SMTP authentication. Anyway, I suppose it is time to move on and remove it finally.

 

[fln]

Thanks for clarification, I assumed accidental leftover from old times. For anyone using pophosts feature - the feature is removed in 1.646 release. DA 1.646 will not update this file anymore.

 

[dmtinc]

Following with the "./build update" case, if you have enabled the custombuild cron with:

cron=yes
notifications=yes
updates=yes
webapps_updates=yes

The custombuild wont honor the autoupdates=0 in directadmin.conf and directadmin will be updated without any notification.

2023-01-06 06:00:04 : called: install
2023-01-06 06:00:04 : DirectAdmin update requested
2023-01-06 06:00:06 : called: cron_execute

If you check the code, the "webapps_updates" includes update DirectAdmin:

command_cron_execute() {
        BOLD_OPT=no
        boldon=""
        boldoff=""

        local output
        output=$(doVersions 1 | grep -F 'update is available.')
        if [ -z "${output}" ]; then
                return
        fi
        if [ "${NOTIFICATIONS_OPT}" = "yes" ]; then
                local subject count
                count=$(wc -l <<< "${output}")
                subject="${count} updates available for ${HOSTNAME}"
                if [ "${UPDATES_OPT}" = "yes" ]; then
                        subject="${count} updates running for ${HOSTNAME}"
                fi
                if command -v s-nail > /dev/null; then
                        s-nail -s "${subject}" "${EMAIL_OPT}" <<< "${output}"
                else
                        mail -s "${subject}" "${EMAIL_OPT}" <<< "${output}"
                fi
        fi
        if [ "${UPDATES_OPT}" = "yes" ]; then
                exec_with_lock doVersions 0
        elif [ "${WEBAPPS_UPDATES_OPT}" = "yes" ]; then
                doVersions 2
        fi
}

doVersions() {
        cd ${WORKDIR}

        if [ "$2" = "full" ]; then
                if distro_is_debian; then
                        apt-get update
                        apt-get -y upgrade
                elif distro_is_rhel; then
                        yum -y update
                fi
                doUpdateDA
        fi

 

[fln]

@dmtinc, yes autoupdates=0 only controls internal DA web service auto update mechanism (when DA periodically checks if there are new versions and updates itself). It has nothing to do with CustomBuild. Calling ./build update manually or using cronjob to call it will update DA. It is the same as calling da update manually from CLI.

Edit: CB cronjob does doVersions 1 to collect updates available, if you have updates=yes in options.conf it will also call doVersions 0 which will rebuild software components and update DA. Cronjob will never do doVersions full (the snippet you have pasted). DA update in doVersions 0 is further down in the CB sources.

Edit 2: Internal DA auto update mechanism supports gradual rollout. We release new versions slowly and do not update all servers at once. Default rollout window for new releases are 7 days. For hot fixes they are rolled-out much faster. Systems with CB cronjob enabled and having with updates=yes completely disregards the rollout rules and immediately upgrades DA at the time when cron-job is executed. The ability for CB cronjob to update DA is left there for backwards compatibility since it were doing it before.

 

[sparek]

The binding of CustomBuild to DirectAdmin updates (and thus effectively removing CustomBuild as being a separate entity) obviously has had more repercussions than was thought about when this decision was made.

Makes me wonder what other decisions are being made behind the scenes that aren't being given enough thought before being rolled out. Starting to sound like another product on the market.

 

[dmtinc]

@dmtinc, yes autoupdates=0 only controls internal DA web service auto update mechanism (when DA periodically checks if there are new versions and updates itself). It has nothing to do with CustomBuild. Calling ./build update manually or using cronjob to call it will update DA. It is the same as calling da update manually from CLI.

So we cant have automatic updates for webapps like roundcube or phpmyadmin without forcing update directadmin, I'm still with my point, as "custombuild" its part of Directadmin, honoring the Directadmin configuration options its a must. Whats the point of all this integration of custombuild as part of Directadmin if still be a "hack" script with own rules.

and We are not talking about to create a totally new script to honor almost the autoupdate option:

doUpdateDA() {
       
        /usr/local/directadmin/directadmin update 2>/dev/null

        writeLog "DirectAdmin update requested"
}

can be

doUpdateDA() {
       
export $(da config | grep autoupdate | xargs)
if [ "${autoupdate}" == "1" ]; then
               
        /usr/local/directadmin/directadmin update 2>/dev/null

        writeLog "DirectAdmin update requested"

        else
               echo "autoupdates for Directadmin are disabled at directadmin.conf"
        fi
}

 

[fln]

@dmtinc we are moving towards complete DirectAdmin and CustomBuild integration, but this is not something we can do in a single step. Next step would be to deprecate DA autoupdates via CustomBuild leaving only DA built-in auto-update functionality. Much simpler than re-implementing gradual rollout in CustomBuild.

@sparek we really like the DirectAdmin and CustomBuild merge. This makes it much easier to ensure software compatibility compared to the situation we had before where you could be running very old DA with latest CB, or latest DA with extremely old CB. Without tight coupling of DA and CB we could not easily make the native CustomBuild integration in Evolution we have right now. So long story short - we knew very well this will be a breaking change (breaking change in DA/CB behaviour) and the consequences it would bring, and pros of this decision still out-weights the cons .

 

[Ohm J]

this DA and custombuild better than before ( I don't want to face with some weight apache going down without reason like in version 2.4.52 - 2.4.53).

it good thing when EOL OS, but people want to keep running their system without upgrade and just want custombuild work without force stop functional.

but it should deprecate option " ./build update " or remove it.

 

[Richard G]

but it should deprecate option " ./build update " or remove it.

I disagree about that. Too much is still going wrong and some (like me) still want to do the updates manually and monitor them as they are compiled by custombuild.
And only update them if we want to update them. For example, we now suspend the php 8.1 security update because of all the issues DA now has when upgrading to 1.6.4.6. I don't want all this fuzz which is happening on almost every DA update.

I understand why they are merging the stuff, and if it all works flawlessly then it's indeed better, but one should not remove that ./build update option until it really does. And as far as I can see it, we're still nowhere near that point.

 

[dmtinc]

@dmtinc we are moving towards complete DirectAdmin and CustomBuild integration, but this is not something we can do in a single step. Next step would be to deprecate DA autoupdates via CustomBuild leaving only DA built-in auto-update functionality. Much simpler than re-implementing gradual rollout in CustomBuild.

@sparek we really like the DirectAdmin and CustomBuild merge. This makes it much easier to ensure software compatibility compared to the situation we had before where you could be running very old DA with latest CB, or latest DA with extremely old CB. Without tight coupling of DA and CB we could not easily make the native CustomBuild integration in Evolution we have right now. So long story short - we knew very well this will be a breaking change (breaking change in DA/CB behaviour) and the consequences it would bring, and pros of this decision still out-weights the cons .

This is my case, with the 1.645 release, all the problems was fixed after 11 hotfixes , when a problem goes live we as hosters can get hundreds of reports of our clients, for you can be only one license, for us can be 100 clients , so to avoid this for this week I configured on all my directadmin instances "autoupdate=0", but today all my servers are on the 1.646 version caused by the custombuild cronjob, and at 8 AM (GMT-3) we start to get reports of problems (the json problem fixed in the first hotfix of this release), the DirectAdmin staff need to see this from our shoes, and if I'm (We?) discussing this isnt for fun, this is a real problem(dont have a real control of when an update its applied) for our me (us?) as service provider.
You can said "so why you dont change the update channel to stable", yesterday (and still today) the stable version is 1.644 and based on the custombuild behavior all my DA instances will be downgraded from 1.646 to 1.644

# dig stable-version.directadmin.com txt +short
"v=1.644&commit=2138cff12eb6d60eec6bde18b2bf38b208f9ae51&rt=2022-11-23T13:22:23Z&du=168h&df=24h"

So if you are on the 1.645 version isnt way to still in that version if you are using custombuild cron or ./build update, the only choices are 1.644 or 1.646....

May be a way to avoid this kind of situations, bump the stable version before the release of the new version, at least 10 minutes before (based on the dns TTL of 5 minutes of stable-version.directadmin.com txt record).

and "we are moving towards complete DirectAdmin and CustomBuild integration, but this is not something we can do in a single step.", I agree with this, but this change in custombuild can be done "quickly" without integrate all the functions in one step, as a "hotfix"

 

[sparek]

@sparek we really like the DirectAdmin and CustomBuild merge. This makes it much easier to ensure software compatibility compared to the situation we had before where you could be running very old DA with latest CB, or latest DA with extremely old CB. Without tight coupling of DA and CB we could not easily make the native CustomBuild integration in Evolution we have right now. So long story short - we knew very well this will be a breaking change (breaking change in DA/CB behaviour) and the consequences it would bring, and pros of this decision still out-weights the cons .

I don't agree with this.

So if a huge security hole is discovered in Apache - we'll all have to update DirectAdmin in order to get the new version of Apache? Dovecot 2.3.20 became available in this DirectAdmin update. Dovecot 2.3.20 was released on December 22, 2022. Granted, as far as I know it wasn't a security release - but what if it had been? What if there was an administrator facing one of the issues that Dovecot 2.3.20 fixed? "Wait 2 weeks until we release a new DirectAdmin version, then you'll get access to the Dovecot 2.3.20 update."

A control panel is a control panel. Essentially a control panel is offering Apache, Exim, Dovecot, etc as a courtesy to the overall server stack. A control panel is there to provide an interface such that when this button is clicked, this action is performed - hookable events. Most of those hooks are oblivious to the user/administrator - add a new account in DirectAdmin then this gets written to the Apache VirtualHost file, this gets written to the Exim list, etc., etc. - but at it's core that's all a control panel is.

Dollars to donuts, the reason this integration happened was because there were a lot of DirectAdmin users that were just using DirectAdmin for the web hosting stack (i.e. LAMP) and not paying for the DirectAdmin license but still getting updates via CustomBuild. Instead of fixing it so that CustomBuild did a licensing check - you decided to take the easy way and integrate CustomBuild into DirectAdmin.

The other control panel started going downhill when they decided to become a one-stop server administration management package - offering everything you need to manage a web hosting server, no knowledge required. DirectAdmin is going down this same path by deciding that they know what is best for us without even asking.

None of the other control panels on the market have this type of integration. You've upset a lot of DirectAdmin users with this decision. And I think it's a real possibility that you're going to lose the market share you gained with this decision. There was no discussion about implementing this - it was just a unilateral decision you made.

While keeping the core DirectAdmin control panel up to date is important - as you can see with this thread and all of the other threads with new DirectAdmin updates, all of the hot fixes that have to be pushed out - there is a reason that people don't jump on a DirectAdmin update as soon as it's released. I'm not disputing the hot fix solutions - but some of us would rather wait for these bugs to get squashed in their entirety before updating DirectAdmin. But we can't reap the benefits of updated stack applications until we update DirectAdmin.

 

[Richard G]

Totally agree with that. Merging is not a bad idea, but keep the panel and software update seperately. Even the biggest competition has seperate panel and software update (easyapache and just using yum next to it). No need to update CP to be able to update apache or php or whatever is needed.

 

[Erulezz]

Granted, as far as I know it wasn't a security release - but what if it had been? What if there was an administrator facing one of the issues that Dovecot 2.3.20 fixed? "Wait 2 weeks until we release a new DirectAdmin version, then you'll get access to the Dovecot 2.3.20 update."

While i agree with most of the things discussed in the latest posts, just a friendly reminder that we don’t have to wait before these packages are released by DirectAdmin. We can just manually download Dovecot or PHP and let CustomBuild compile it. That’s what i do with Composer for example.

That being said; i like the tighter integration of DirectAdmin and the CustomBuild script/plugin. Bundling new PHP / Dovecot / etc with DA releases is just weird and i’d like that to be changed back.

There are some nice improvements again in this update so i’m happy overall

 

[Erulezz]

@fln is there any reasoning for adding letter-spacing: .5px; to the new system information page? Text looks a bit different from other pages. It's very small but noticeable.



Again, very minor thing but with letter-spacing: .5px; disabled it looks much better and more in line with all other pages.

 

[fln]

Lets keep this thread for discussions related to DA 1.646 release. I will try to be concise.

So if a huge security hole is discovered in Apache - we'll all have to update DirectAdmin in order to get the new version of Apache?

No, within a 5 minutes we could release any software upgrade to any release channel (without updating DA, just apache, php, etc..). This is what the hot-fix updates system are for. We could be releasing 3rd party software upgrades at the same rate old CB upgrade used to do (actually faster, since old CB would upgrade once a day, while DA can apply-hot fix much faster). However we opt not to release it because there were no critical updates.

Our goal is to make smaller releases more often, but right now we are making bigger structural changes to the code-base so it takes some time for new features to accumulate .

So if you are on the 1.645 version isnt way to still in that version if you are using custombuild cron or ./build update, the only choices are 1.644 or 1.646....

We were planning to bump stable to 1.645 on Monday. I agree that it would have been better to bump current and stable at the same time (like we did in 1.645). This time we decided to have a small offset between the releases, for next releases will most likely do the bump at the same time.

This is my case, with the 1.645 release, all the problems was fixed after 11 hotfixes

This is a bit misleading. Some issues affect a tiny fraction of users but because we announce every time we push out update it does not look good. Some of the hot-fixes were version upgrades (php 8.2.0RC6 -> 8.2.0), etc. Some affected only changes in the installer (noops for existing installations but changes how DA would be installed on a fresh server). Most of the changes were CB related. Our DA / CB merge means that any issue that used to be reported in CustomBuild section now gets reported in DA release thread. Most clients keeping auto-updates ON experienced zero problems . But if there is one peculiar configuration that fails on one particular server and user reports it to the forums we release a hot-fix for everyone (even if it is a dead code for everyone else).

so to avoid this for this week I configured on all my directadmin instances "autoupdate=0"

I would not recommend turning OFF auto-updates. If you are not doing manual upgrade, most of the time you will receive the update automatically with the fixes at some later point in time, and there will be no need to manually upgrade.

but one should not remove that ./build update option until it really does

Command ./build update could stay there forever (for updating DA manually). The only problem so far are CB cronjobs combined with automatic software updates. It should continue updating all software but exclude DA, because it makes DA upgrade immediate and does not participate in gradual rollout.

 

[LawsHosting]

No, within a 5 minutes we could release any software upgrade to any release channel (without updating DA, just apache, php, etc..). This is what the hot-fix updates system are for.

I'm comparing apples & oranges here - What if a package is released at 3 pm in Europe, do we need to wait for your staff to wake up and flick a switch?

Seriously, adding packages to hotfixes is one hell of a bad decision..... and if I was still running my business, I'd quit. Sorry to say.

 

[Erulezz]

I'm comparing apples & oranges here - What if a package is released at 3 pm in Europe, do we need to wait for your staff to wake up and flick a switch?

This was also the case with the previous implementation? Someone needed to add it to files1 and then it was available. The difference is that now a new hotfix is released with a new versions.txt.

 

[smtalk]

Even the biggest competition has seperate panel and software update (easyapache and just using yum next to it).

I don't think we need to hide the names If there is a room for improvement - I'd prefer suggestions, instead of going back to the old mechanism where part of DA was split into 2 packages (CB+DA). Even something as simple as MariaDB 10.3 support in CB and old DA brought major problems due to structural changes (mysql.users became a view instead of real table), same happened with MySQL8 and there are many other examples. Control panel needs to be aware of what CustomBuild supports, CustomBuild needs to be aware of what DA supports. Packing them together solves this problem. Many wanted gradual rollout as well. This is why we'd better talk on how we could improve the system, instead of creating the same problems we had Regarding competition, maybe you know their flow better, but checking the changelogs like https://docs.plesk.com/release-notes/obsidian/change-log/ I see changes like:

PHP 8.2.0 is now shipped with Plesk Obsidian 18.0.48 and later on all OSes.

Does not it mean it requires an update of the panel? With the "biggest" I guess you've meant https://docs.cpanel.net/release-notes/104-release-notes/, here I also see entries like:

Roundcube upgrade to 1.5
In cPanel & WHM version 104, we upgraded Roundcube to version 1.5.2. This release includes a spam marking/unmarking feature.

Does not it mean cPanel&WHM 104 is required to run RoundCube 1.5? It makes sense to me, as they can be guaranteed that control panel fully supports it. It'd be appreciated if you may explain how it works then and what did you mean with "seperate panel and software update". Thank you.

No need to update CP to be able to update apache or php or whatever is needed.

DirectAdmin hotfix release could have just a versions.txt change, as @fln already mentioned, one of the hotfixes was simply PHP 8.2.0RC6 -> 8.2.0 change. DirectAdmin code did not change there at all, we knew it supports it, thus only versions.txt change was applied.

 

[dafang]

In 1.646 mobile view, cannot see the full list of available languages on login page.
The list gets truncated on both left and bottom edges.
Cannot scroll the list either horizontally or vertically.
What appears to be excessive blank space on the right edge.
The password eye is visible on the list at all times.

Most of these issues on the login-page language-list seem to persist on desktops, too.