./build versions differs on two identical servers

kristian

kristian

Verified User
Joined
Nov 4, 2005
Messages
439
Location
Norway
Hi!

I've been lately seeing a bit of a strange problem for me. I regularly run ./build update followed by ./build versions (or versions_json) to report any available updates to my monitoring system. For a long time, all my servers have alerted me at the same time that updates are available. But recently, only some of the servers do this, while others seem to not be able to identify these new updates.

Example:

web39:
Code: 
# cd /usr/local/directadmin/custombuild
# ./build version
2.0.0
# ./build update
# ./build versions_json
{
}
# ls -l versions.txt 
-rw-r--r-- 1 root root 2264 Oct  8 07:30 versions.txt
# grep ^downloadserver options.conf 
downloadserver=files1.directadmin.com

web40:
Code: 
# cd /usr/local/directadmin/custombuild
# ./build version
2.0.0
# ./build update
# ./build versions_json
{
    "php_expert 8.0 php-fpm": {
        "name": "PHP 8.0",
        "current": "8.0.24",
        "offered": "8.0.25"
    },
    "php_expert 8.1 php-fpm": {
        "name": "PHP 8.1",
        "current": "8.1.11",
        "offered": "8.1.12"
    }
}
# ls -l versions.txt 
-rw-r--r-- 1 root root 2264 Oct 28 21:40 versions.txt
# grep ^downloadserver options.conf 
downloadserver=files1.directadmin.com

What is causing these two servers to report different available versions?
 
Hello,

I don't understand the new logic in a full yet. The versions.txt does not get updated the way we used to it. But this might help and pull a list of updates:

Code: 
./build update_da

Yes, that's the command to update DirectAdmin. But it seems it's now required to get the latest versions.txt file. CustomBuild script is now shipped with directadmin updates.

So you might give it a try. If it does not help, then the debian version might be the reason too.
 
Running ./build update_da made no difference, and it also didn't output anything. I can't find anything in the logs either about unsupported OS. I tried to run (on web39) ./build update now after adding -x to the #! for debug output, but couldn't really see anything obvious in that (long!) output either.

Another interesting observation I just made now, after going to run with -x on web40 as well, was that on web39 the script uses /bin/sh as the interpreter, but on web40 it's using /bin/bash. Despite both scripts reporting they're both version 2.0.0, they're not the same:

web39:
Code: 
# md5sum build
f61442f8469defaa7d92b467df7225da  build
# wc -l build
25528 build

web40:
Code: 
# md5sum build
f9994426b99e77f0e952d99809e90ece  build
# wc -l build
24294 build

Did someone forget to update the version somewhere? Because this is just downright confusing! :)
 
I didn't know that unsupported also meant "quietly failing, and refusing to update anything". I think it would be beneficial to output something about EOL for commands that no longer work.

I'm on the default channel, which seems to be "current".
 
Not too sure how is it on Debian 9, but on CentOS 6 the new version of custombuild script reports:

Code: 
RHEL/CentOS 6 is not supported by DirectAdmin anymore.

on any attempt to use the ./build script.

I guess the current version of custombuild script should report the same on Debian 9:

Code: 
Debian 9 is not supported by DirectAdmin anymore.

I see the line the ./build script on my server at least.
 
I see the line/check in the sciript on both servers, but the check is only against 7 and 8, so wouldn't trigger on Debian 9. If the script doesn't want to update itself because it's running on Debian 9, and thus will never get the check against Debian 9 so it can complain, then I think this check should be handled differently. :)

In any case, I will be upgrading the Debian 9 servers shortly, so I'll just leave this as is. But I think the build script could benefit from some more informational output in these situations.

Thanks for your feedback, Alex!
 
You must log in or register to reply here.
Back
Top