CustomBuild automatic updates cron logic flawed?

HindrikOxilion

Verified User
Joined
Sep 23, 2011
Messages
33
Hey everyone,

We're setting up some new CentOS 8 servers with DirectAdmin. When enabling the automatic update feature for DA only, a daily cronjob is created by the CustomBuild script thusly:
if [ "${UPDATES_OPT}" = "no" ] && [ "${DA_AUTOUPDATE_OPT}" = "yes" ]; then
echo './build update_da' >> ${CRONFILE}
fi

This results in the following relevant section in the CRONFILE /etc/cron.daily/custombuild:
cd /usr/local/directadmin/custombuild
./build update >/dev/null 2>&1
AVAIL_UPDATES="`./build versions_nobold | grep -c -e 'update is available.'`"
if [ "${AVAIL_UPDATES}" -gt 0 ]; then
./build update_da
fi

Since we have chosen to start with only enabling auto-updates for DirectAdmin itself, and not the rest of the CB software (I won't go into reasons why ;), this creates an issue. When running the 'update_da' CB command, there is always output, which is then mailed by the crond:

Updating DirectAdmin

This in itself is not really a huge issue, but since the check triggers an update for all other versions too, it will continue to perform a DA update every day while there are also newer versions available for any other CB software. This causes a cron-mail every day with the text "Updating DirectAdmin", as long as there is other software to be upgraded.

I personally think the logic is flawed, the cron should only check for updates for DirectAdmin itself, and not all updates, when the option is specifically chosen to not update all other software and only DA itself.

So, my suggestion would be that CustomBuild script be changed. The check/trigger to perform the 'update_versions' command should include the line:
echo "AVAIL_UPDATES=\"\`./build versions_nobold | grep -c -e 'update is available.'\`\"" >> ${CRONFILE}

But the check/trigger to only 'update_da' should only match if there's an update for just/only DirectAdmin, something like:
echo "DA_UPDATE=\"\`./build versions_nobold | grep -q -e 'DirectAdmin update is available.'\`\"" >> ${CRONFILE}

Followed by:
if [ "${DA_UPDATE}" ]; then
./build update_da
fi

Something to that effect.

I know that we simply could enable all automatic updates, or none, but this is a choice that is explicitly split by CustomBuild itself, so it should work accordingly in my opinion... ;)

TL;DR: Only check for DirectAdmin update if only DirectAdmin auto-update is enabled
 
May you try CustomBuild 2.0 rev. 2574 ? Thank you for the request!
 
Dear Martynas,

Thank you for your quick (re)action! I've downloaded the new CB script, and at first glance it seems to do exactly what I had in mind ;)

However, upon testing some more (even more than I had initially done, so sorry) it appears that the logic still updates DirectAdmin itself when "updates=yes" and "da_autoupdate=no", meaning the opposite set of options to what I had initially discovered/tested.

The same seems to be true for the situation where "webapps_updates=no" and "updates=yes". It also updates all versions with a "update_versions" command.

To be clear: I'm not trying to argue that we "need" an option to be able to update everything except DirectAdmin itself. No real-world application springs to mind immediately. But, as the CB script does provide 3 seperate auto-update options, I started digging into the actual workings of the 8 possible permutations.

As a visual/textual aid, I've described all 8 possible option-sets for the 3 auto-update options, and their respective actions put into the cron:

  1. "da_autoupdate=no" && "updates=no" && "webapps_updates=no":
    no updates are performed, all available updates are notified by mail.

  2. "da_autoupdate=no" && "updates=no" && "webapps_updates=yes":
    Only webapps are updated, all available updates are notified by mail, including the webapps that are automatically updated.

  3. "da_autoupdate=no" && "updates=yes" && "webapps_updates=no":
    All updates, including DA itself and the webapps, are performed, notification is mailed that "updates are running".

  4. "da_autoupdate=no" && "updates=yes" && "webapps_updates=yes":
    All updates, including DA itself, are performed, notification is mailed that "updates are running".

  5. "da_autoupdate=yes" && "updates=no" && "webapps_updates=no":
    Only DA update is performed, all available updates are notified by mail, including DirectAdmin which automatically updated.

  6. "da_autoupdate=yes" && "updates=no" && "webapps_updates=yes":
    DA and webapps are updated, all available updates are notified by mail, including DirectAdmin and webapps, which are automatically updated.

  7. "da_autoupdate=yes" && "updates=yes" && "webapps_updates=no":
    All updates are performed, including the webapps which should not, notification is mailed that "updates are running".

  8. "da_autoupdate=yes" && "updates=yes" && "webapps_updates=yes":
    All updates are performed, notification is mailed that "updates are running".
Summarizing, it seems the "updates=yes" option always overrides any preference set for "webapps_updates" AND "da_autoupdate". I'm not sure what the quick and dirty fix would be, since the "update_versions" command always builds all software, including DirectAdmin and the webapps.

Anyway, our initial desire to only have DirectAdmin silently updated seems accomplished now, so thanks for that! I will leave it yourself and others to decide if the CB auto-update logic should undergo further tuning ;)

Edit/Addition:

One thought did spring to mind after posting: since the "update_versions" is the largest set of updates, it might just be an idea to switch from 3 seperate toggle-options to a dropdown/selection of just the 5 effective option-sets:
  1. No updates, (default?)
  2. Only update DA,
  3. Only update webapps,
  4. Update both DA and webapps,
  5. Update all, including DA and webapps.
This would encompass more changes to the build script as well as the options.conf file and the plugin interface. This may bring about compatibility issues for those who are versioning their options.conf outside of CustomBuild, via puppet for example, so I'm not sure this is the right way to go, just a suggestion ;)
 
Last edited:
Perhaps add: update OS packages (yum update, apt-get, depending on OS)
I'd just like to chime in here, and suggest using existing package updating mechanisms for OS packages (yum-cron, unattended-upgrades, etc) instead of baking that into DA/Custombuild. Whether or not DA/Custombuild could/should call these other tools is another question though.

If there are any tasks that should be taken (e.g. recompile?) in DA/Custombuild after a successful OS package update, it might validate baking something in, or supporting some sort of trigger/hook mechanism.
 
Dear Martynas,

Thank you for your quick (re)action! I've downloaded the new CB script, and at first glance it seems to do exactly what I had in mind ;)

However, upon testing some more (even more than I had initially done, so sorry) it appears that the logic still updates DirectAdmin itself when "updates=yes" and "da_autoupdate=no", meaning the opposite set of options to what I had initially discovered/tested.

The same seems to be true for the situation where "webapps_updates=no" and "updates=yes". It also updates all versions with a "update_versions" command.

To be clear: I'm not trying to argue that we "need" an option to be able to update everything except DirectAdmin itself. No real-world application springs to mind immediately. But, as the CB script does provide 3 seperate auto-update options, I started digging into the actual workings of the 8 possible permutations.

As a visual/textual aid, I've described all 8 possible option-sets for the 3 auto-update options, and their respective actions put into the cron:

  1. "da_autoupdate=no" && "updates=no" && "webapps_updates=no":
    no updates are performed, all available updates are notified by mail.

  2. "da_autoupdate=no" && "updates=no" && "webapps_updates=yes":
    Only webapps are updated, all available updates are notified by mail, including the webapps that are automatically updated.

  3. "da_autoupdate=no" && "updates=yes" && "webapps_updates=no":
    All updates, including DA itself and the webapps, are performed, notification is mailed that "updates are running".

  4. "da_autoupdate=no" && "updates=yes" && "webapps_updates=yes":
    All updates, including DA itself, are performed, notification is mailed that "updates are running".

  5. "da_autoupdate=yes" && "updates=no" && "webapps_updates=no":
    Only DA update is performed, all available updates are notified by mail, including DirectAdmin which automatically updated.

  6. "da_autoupdate=yes" && "updates=no" && "webapps_updates=yes":
    DA and webapps are updated, all available updates are notified by mail, including DirectAdmin and webapps, which are automatically updated.

  7. "da_autoupdate=yes" && "updates=yes" && "webapps_updates=no":
    All updates are performed, including the webapps which should not, notification is mailed that "updates are running".

  8. "da_autoupdate=yes" && "updates=yes" && "webapps_updates=yes":
    All updates are performed, notification is mailed that "updates are running".
Summarizing, it seems the "updates=yes" option always overrides any preference set for "webapps_updates" AND "da_autoupdate". I'm not sure what the quick and dirty fix would be, since the "update_versions" command always builds all software, including DirectAdmin and the webapps.

Anyway, our initial desire to only have DirectAdmin silently updated seems accomplished now, so thanks for that! I will leave it yourself and others to decide if the CB auto-update logic should undergo further tuning ;)

Edit/Addition:

One thought did spring to mind after posting: since the "update_versions" is the largest set of updates, it might just be an idea to switch from 3 seperate toggle-options to a dropdown/selection of just the 5 effective option-sets:
  1. No updates, (default?)
  2. Only update DA,
  3. Only update webapps,
  4. Update both DA and webapps,
  5. Update all, including DA and webapps.
This would encompass more changes to the build script as well as the options.conf file and the plugin interface. This may bring about compatibility issues for those who are versioning their options.conf outside of CustomBuild, via puppet for example, so I'm not sure this is the right way to go, just a suggestion ;)
if you really want these types of enhancements to the system you have to post on the Feedback site. https://feedback.directadmin.com/
 
Back
Top