Again the auto updating

ItsOnlyMe

Verified User
Joined
Apr 3, 2009
Messages
124
Location
Netherlands
Can someone explain to me WHY on earth Directadmin has started to auto update itself again without bumping the version number and even with autoupdate and autopatch on 0?

Code:
[root@webXXXX ~]# stat /usr/local/directadmin/directadmin
  File: ‘/usr/local/directadmin/directadmin’
  Size: 27679608        Blocks: 54072      IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 164384      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-26 02:02:06.469696362 +0100
Modify: 2023-01-26 02:02:06.704697868 +0100
Change: 2023-01-26 02:02:06.704697868 +0100
 Birth: -
 
 
[root@webXXXX ~]# /usr/local/directadmin/directadmin c | grep -i auto
auto_add_global_ip=
autopatch=0
autoupdate=0
letsencrypt_background_default=auto


[root@webXXXX ~]# /usr/local/directadmin/directadmin v
DirectAdmin v.1.646 1e41a5311372d2ce3a4ec360f7c399e2e39635ab

When I look at a backup that has been taken a few minutes before the modify timestamp of the Directadmin binary I get this:
Code:
root@backupXXXX:/tank/webXXXX/.snapshot/SNAPSHOTID-947546/directadmin# stat directadmin
  File: directadmin
  Size: 27679608        Blocks: 54284      IO Block: 131072 regular file
Device: 55h/85d Inode: 1664        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-23 12:00:32.713560380 +0100
Modify: 2023-01-19 12:05:39.000000000 +0100
Change: 2023-01-23 12:00:32.713560380 +0100
 Birth: -
 
 
root@backupXXXX:/tank/webXXXX/.snapshot/SNAPSHOTID-947546/directadmin# ./directadmin v
DirectAdmin v.1.646 4c1ce354769edcc8e41673bf5d414bfa4cb78c6a

Clearly visible that the hash has changed of the binary so explain to me how Directadmin has been updating itself on multiple servers last night without bumping the version itself and autopatch+autoupdate on 0.

I think its time to start looking for a new panel with all the issues that I have been seeing in the last 2 years or so.
 
CustomBuild=DA, whichever you update, you get the other one updated as well. My guess is that you’ve updated CutomBuild there, which is in the same package.
 
We didn't update, i was asleep at the time this stuff happend man. Its starting to do my head in all these "auto" update or whatever the f*** is happening.

On 2023-01-26 02:02:06 it auto updated with the values on 0 for autoupdate and autopatch. And no, we do NOT use the cron for this to update stuff. No-one was on this server at the time. I log all SSH commands anyone runs as root. And there hasn't been any activity on that time. So. again why did it auto update on multiple servers the same night?

And how can the hash of the directadmin binary it self change if it hasn't been updated by us?
 
Or is it now that whenever you run a ./build update it will update directadmin also?? if so, since when is this and where is it noted that this is a thing these days?
 
Or is it now that whenever you run a ./build update it will update directadmin also?? if so, since when is this and where is it noted that this is a thing these days?
Yes, this updates DirectAdmin now. This bit me too.

This all started because of DirectAdmin's decision to bundle DirectAdmin (the control panel) and CustomBuild (the web stack controller) together into one thing. Wrong decision in my opinion, but either I'm the only one that feels this way as nobody else seems willing to speak out about it or it doesn't matter we could all argue until we're blue in the face and it still won't change things.

The reason for this is that /usr/local/directadmin/custombuild/build update was always meant to update the version numbers available for the web stack software. Well, in order to do that now, you have to update DirectAdmin (the control panel) to the latest version, so in essence, /usr/local/directadmin/custombuild/build update is still performing this task... it's just now also updating DirectAdmin (the control panel) to the latest version.
 
./build update now updates DA.
Well that is not a real big change, it has always updated DA. Or at least was possible this way. But also possible to leave that out.

Maybe they wanted to remove it, and then decided to have it update DA again. But you should now it was always possible to update DA via the ./build update command.

so ./build update does nothing anymore in that area.
Nothing in either post you pointed to mentioned anything in that direction, in the contrary.

It was specifically asked in another thread. Indeed versions.txt are now bundled with DA, so that means you can't update applications like before without updating DA.
So if there are application updates, it's now bundled with DA, so you have to do a ./build update to update DA and then you can do a ./build update_versions to update all applications.

It still works like this, I even updated apache yesterday this way.

And there was a discussion also about it, because some of us, including me, are not happy about this, because this means you can't update applications anymore without updating DA when DA is again released with a load of bugs like happens more often lately.

Edit: Ah posting at same time as Sparek.

Edit2: We in fact agree, only you explained wrong Erulez, the "nothing" is incorrect, it does work, but not anymore as before.
 
Well that is not a real big change, it has always updated DA. Or at least was possible this way.
No, I don't think this was the case. Admittedly, it's hard to argue because we can't check this any more.

But I as I recall /usr/local/directadmin/custombuild/build update just retrieved a new version of versions.txt for CustomBuild. So if there was an Apache update available, you would run /usr/local/directadmin/custombuild/build update and then /usr/local/directadmin/custombuild/build versions would show that Apache has an update. It never actually updated DirectAdmin (when CustomBuild was it's own separate thing). To update DirectAdmin (the control panel) you would have run /usr/local/directadmin/custombuild/build update_da.

At least that's how I remember it.

I suspect the OP is doing something like I was doing. I had a daily cron task set to notify me of new versions in CustomBuild. To do that I ran /usr/local/directadmin/custombuild/build update and then piped /usr/local/directadmin/custombuild/build versions (actually /usr/local/directadmin/custombuild/build versions_json) through a mail script to notify me. That inadvertent /usr/local/directadmin/custombuild/build update is now updating DirectAdmin to the latest version. Took me a little while to learn this as well. Wasn't too happy about it. Still ain't none too happy about it.
 
No, I don't think this was the case.
I'm 100% sure it was possible as configurable function. Edit: almost sure, not 100%. ;) Room for memory leak.
As far as I remember we could disable the updating of DA itself in options.conf or directadmin.conf. Might be even this setting.
This da_autoupdate=no setting was not only for cron as far as I remember and that setting is there many years. We used it to disable DA from updating via the build command once the DA releases started to have several isseus almost every release. Even stated that in some post somewhere.
The ./build update_da command is only since 1.640 (you can check in the changelog).

Anyway, that's in the past now, it won't work like that anymore in any case. And I'm still not too happy about it either.



However, you are correct anyway that the ./build update did update the versions.txt file.
This made it possible to seperately update DA or seperately update the applications.

Might indeed be correct what you said that the OP did something wrong with the cron. However the ./build versions is just an output of the content of the versions.txt file. Good you found out that caused an issue.
 
Last edited:
Yea, as you say - it doesn't really matter any more now. You've been using DirectAdmin a lot longer than I have, so it may have acted that way at some point.

I know the script I was calling in a custom cron entry to check CustomBuild used a function:

function checkcustombuild_json() {
shell_exec("/usr/local/directadmin/custombuild/build update >/dev/null 2>/dev/null");
return json_decode(trim(shell_exec("/usr/local/directadmin/custombuild/build versions_json")), TRUE);
}


To get CustomBuild updates. Prior to the DirectAdmin (the control panel) and CustomBuild (the stack controller) being integrated, this would tell me if the DirectAdmin servers had any CustomBuild updates.

I remember going ape #%! ballistic when I was finding that our DirectAdmin servers were updating their control panel version, when I explicitly had auto updates turned off. In fact this cron script was supposed to tell me if there was a DirectAdmin (the control panel) update. Finally realized it was this /usr/local/directadmin/custombuild/build update that was updating DirectAdmin (the control panel) but technically, it did also serve to show CustomBuild (the stack controller) updates as well.

I've now disabled this function in the cron script - so now I'm oblivious to when stack applications have updates available. I haven't yet figured out a good way to resolve this. Is there a new version of Apache in CustomBuild? I don't know. I won't know until I decide to dip my toes into another DirectAdmin update.

I've described this decision to integrate DirectAdmin (the control panel) and CustomBuild (the stack controller) as being stupid. And maybe that's too strong of a word. I suppose it's taken me out of the good graces with the DirectAdmin development team (not sure I was ever in the good graces). But I think if you're going to build a successful company you have to be able to take constructive criticism, if you surround yourself with "Yes men" you're going to be in a world of hurt eventually. Nobody especially likes criticism, I don't either. It's just human nature to try and defend the decisions you make. I remember writing an application several years ago for a customer and I was criticized for the way I did some things in it, I defended my reasons for doing it my way. A couple of years later, I looked at the project again and the customer was right, why I did things the way I did was just stupid. Point being is that when you're developing something or making a change to something, you can sometimes get tunnel vision and you see your reasons as being righteous, but some reasonable outside perspective can sometimes help.
 
Well that is not a real big change, it has always updated DA. Or at least was possible this way. But also possible to leave that out.
Correct, You always could update indeed with this but as @sparek says you always would ran ./build update and then ./build versions to get a recent list of the newer versions.

I had a script made that would run every night on all servers that would do these 2 steps and then loop over the output to put the current running versions and newer versions of the software into sql.
I've now disabled this function in the cron script - so now I'm oblivious to when stack applications have updates available. I haven't yet figured out a good way to resolve this. Is there a new version of Apache in CustomBuild? I don't know. I won't know until I decide to dip my toes into another DirectAdmin update.
This is my issue as well now. I really don't understand why this change had been made like many other over the last few years. I understand that some changes are needed or stuff could be done better etc.

It would be nice if some changes big or small, we could vote on if its needed or not. I think there are a lot of users on here that use Directadmin for the options you always had to customize you servers. I feel the way we always could is not here anymore.

I also saw that running a ./build "software" also was starting to make changes to my custom/ap2/configure.* file. why? The file is here for a reason its not for Directadmin to touch this file.

Anyways, I'll go and start changing these cronjobs and make sure they wont run anymore. Thanks
 
you can sometimes get tunnel vision and you see your reasons as being righteous, but some reasonable outside perspective can sometimes help.
I fully agree to that.

However the team, certainly FLN has tried to explain why this integration is done. And I can understand the whay they are thinking. Custombuild (not the plugin) was in fact already Directadmin. Nobody used DA without custombuild anymore. Everyone was over from CB 1.x to 2.0 and every update was done via CB. And then the plugin was added too at a later time to make life easier for some.

Looking at it this way, it's in fact logic that CB is integraged in Directadmin.
The only thing they did not take in account, is the fact that sometimes (and lately a lot) a DA release can have issues and even bugs.

If this happens at the same time, or shortly before some important application updates like PHP, Apache, Mysql/MariaDB, then it should have been known that there will be people who want to update the updates (and certainly security fixes) without having to update to a DA version with issues.

I'm sure the thought behind this was to release better DA updates and if something is wrong, it's fixed within a couple of days, so updates still would be fast. Unfortuntaly fixes are brought up quite fast, but also still too many.
That is a learning curve for them, so I understand the problem seen through DA's eyes. Not every big change is working flawlessly directly, some things take a little time.

On the other hand, I still think there should be an option to be able to update security fixes like for PHP, without having to update the DA version. Or at least until they get a better situation with getting DA under control so less issues on a release are discovered.
But since they don't want to go back to a versions.txt file, I don't think this is to be expected in the near future. Unfortunately.

I still don't like DA getting more and more CP alike. But I'm a very small business. From a business point of view (getting customers and earning money) I'm still not happy but I can understand their choice for this integration.
 
Back
Top