DirectAdmin v1.650 has been released

Would be awesome to have an option to supress (disable) "System updates" via options.conf or directadmin.conf.
Hate it that DirectAdmin now decides (for me) when I install those system updates. When I do not update right away, I will get e-mails over and over again alerting me there are updates ready untill the updates are installed or disable the whole e-mail option.

I just don't want to update via DirectAdmin as I want to decide when, how to update as well would like to decide which files to replace and which not - which isn't possible via DirectAdmin.
 
fln said:
Right now instead of silently creating a partial backup (where we backup config files but not home dir file) we fail the whole backup operation.
Click to expand...
Would a better venture in all of this be focusing on the ability to split or exclude the user's home directory from an admin generated user backup?

Reason being... the home directory can very simply be backed up independently. Using rsync to send the contents of the user's home directory to a backup server, for example. But everything else in the backup - the stuff needed to actually recreate the account (I'd also include the user's database dumps in this as well, since those are quite as easy to back up independently) - can't be as easily identified, so a process that tars up all of the everything else might be beneficial. Generally speaking a user's home directory PROBABLY doesn't change that much from day to day - and most of that change is probably mail. Everything else associated with the user's account probably doesn't change much from day to day either... but, the bulk the account is probably going to be in the user's home directory. So tarring up the everything else would likely be a pretty small file and less disk I/O needed to perform all of that every day/night.

I mean, I've hacked together my own way to accomplish this task - but something native from DirectAdmin might be preferable, since then I could be assured that it's (presumably) backing up everything that is needed to recreate the account, sans the home directory.
 
SanderJ said:
The problem is when using the CLI. Running ./build update_versions will only rebuild the PHP-versions that have updates themselves. For example: if 8.1 has an updated, it will be updates. Should 7.4 (like in your example) have no updates pending, it would indeed cause the message "Linked with old ImageMagick". This will only show up when opening the controlpanel. No message is given in the CLI, nor is the PHP-version being rebuild.
Click to expand...
CLI and GUI behaves the same, doing da build versions would report updates to imagic PHP extension:

Code: 
# da build versions
...
Latest version of imagick PHP 7.4 extension: 3.7.0
Installed version of imagick PHP 7.4 extension: 3.7.0 (linked with old ImageMagick)

imagick PHP 7.4 extension 3.7.0 (linked with old ImageMagick) to 3.7.0 update is available.
...
If you want to update all the available versions run: /usr/local/directadmin/custombuild/build update_versions

Runing da build update_versions would actually update imagic PHP extension if needed:

Code: 
# da build update_versions
...
Updating imagick PHP 7.4 extension
...

Note: da build ... is the same as ./build ... without the need to go into custombuild directory (since da command is available in the path from any directory).
 
Richard G said:
Isn't it possible (and a better solution) to just backup files owned by root again?
Click to expand...
  • DA < 1.650, if user home dir has any inaccessible files backup of ALL user home dir files are silently skipped.
  • DA = 1.650, if user home dir has any inaccessible, backup operation fails with error message explaining what happened.
  • DA >= 1.651, if user home dir has any inaccessible, not accessible files are omitted from user home backup other files are still backed up.
This change in DA 1.651 (alpha release channel at the moment) is a workaround. The root of the problem is still there just gives less problems. Restoring user from backup would still be missing the files that were not accessible at the time backup was being made.

Richard G said:
Because we also sometimes make a change in some customers home dir to fix a problem and to prevent him from doing the same mistake again, just don't chown it to the user and leave it as root.
Click to expand...
Backuping and restoring root owned files as part of user backup is a security risk. Could you please share any use case when you think it is appropriate for users to have root owned files in their home dirs? Allowing non accessible files in user home directories is not something we want to support. Please note that user readable root owned files does not cause problems. Backups fails only when encounters files that are not even readable by users (for example root owned dir with 0700 permissions). If files are not readable they serve no purpose (from the users perspective).
Despite next DA version somehow mitigating this issue by still continuing to make backup (just without unreadable files), I would urge anyone encountering failed backups due to permission errors to investigate the root cause for the issue and fix permission on such files.
 
fln said:
Please note that user readable root owned files does not cause problems.
Click to expand...
Aha oke then there is our misunderstanding. I was talking about root owned files which are readable by the user. Sometimes we change some file for them so they can't cause an issue anymore. I don't have an example so quickly anymore, I think we used it on some basic files once where the user deleted all 400 and 404.shtml and all these, and then complaint that they didn't work anymore. Twice.
So we chowned them to root which also prevented him from deleting the public_html directory which he also managed once.
And some other file in another occasion, other user.
Ofcourse they were all left user readable as indeed as far as I know, there is no reason to have root un-accessible files in there.

So I think it was a little misunderstanding then and if user readable root owned files do not cause issues and will be backed up and restored again same way, then all is fine and my comment can be ignored.
 
On the subject of protecting files within the users home directories.

Maybe another solution would be to make the file(s) immutable (chattr +i), they would then still have the same ownership.

It would be a good idea then for DA to do a chattr -R -i /home/usertodelete before deleting the user to not cause problems removing a user's home directory. Also would need to do that before the restore of a backup so it won't fail unable to restore the files.

Write some hook scripts to do it automatically how you want it? (Maybe have a file with the list of users/files that you want to protect after the restore to reset the attribute.)

Hook scripts | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

I haven't tested this to see if it will case any issues with DA backups, but I don't think it will. Haven't had a need to do this myself, the odd time I have had customers delete something it has just taken a few minutes to put back.

Can't always protect everything, could make things unusable. When customers are really being silly charge them for your time to fix things.
 
cjd said:
@ps4all Have you tried this?

Version 1.643 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com
Click to expand...
Thanks... yes i did, after I had to step in at a bunch of people that rent a Dedicated Server at OVH (for ex.) who decided to click Update All, causing their servers ran into issues with grub (which got trashed) after updating. They've had some guy installing their servers and DA a while ago - haven't figured out how and what he did. But eventually it caused a server hang with quite a lot of servers from those people at reboot due to missing the grub bootloader.

First thing they've said when i got it back up and running, next time i just click update all again as it's easiest and fastest to compile/install all updates, and i expect DA doing what their supposed to do, take care of their CP and not the whole system.

Somehow i do agree on that for me it's not an issue, but for end-customers that rent a server with the DA-CP it's the worst CP nowadays. That's why i suggested to hide the system updates (optional via options.conf).
 
@ps4all I have never had any DA updates cause a system to fail to boot properly, the only setting that gets changed on a new install for the grub loader is enabling cgroups. On purpose I even have a few systems to fully auto update, all Debian updates (including a bunch of back-ports) and DA updates of everything, I only have this on a test server and some cheap hosting servers. And always reboot after kernel updates.

Only reason I can see if a OS update fails like that, is someone did a custom install and the update broke something, and if that is what happened they were probably doing something some hacked way (probably manually edited the config files in the boot directory so next grub update over wrote them all).

I have seen some configuration issues because of a change (configuration file needing to be updated and wasn't after the update), or a bug from a new release of a server (not directly caused by DA but by the vendor, Apache bug comes to mind, MySQL from a bad table failed to start, repair table all good again), it's been a reasonably stable platform.

I have a few dozen DA installs that I manage without really any serious issues, even after OS upgrades, it's not a huge sample size to compare with, been using DA since about 2006. Now there has been the odd issue with a DA update causing an issue for itself or a bug in the web interface (which they have been fixed fairly quickly).
 
@cjd As said, I don't know how those servers got installed by the person they used to install their servers. Only thing i know and found out it has something do to with software raid-1 and raid-5 spread over 3 hard drives of 2TB or 4TB each with OVH. Already told them to drop Raid-5 cause it's just useless and causes a very long sync time causing those servers not beïng reachable during the monthly check (and also really doesn't make sence with what they use it for) :ROFLMAO:

Anyway... it's up to them but I somehow do agree on the part of DirectAdmin should be taking care of the things they are for thus everything around DA/CB etc. Instead of taking care of updating the whole server. Some people do have things customized on their servers which might break and is not taken into concideration atm.
 
We also have problems with the Admin backups.
We see these errors on multiple servers:
Code: 
/bin/tar: .bash_history: Cannot stat: No such file or directory
/bin/tar: Error is not recoverable: exiting now

lstat('/backups/srv1/admin.654866.68oizzDgwqUYJEsXMvmmuRbPYF3Lf6Pl/klmFL76qkIB4IZprg8f7sMprD7aG5Xen/usernamehere/backup/home.tar.zst'): No such file or directory

Code: 
/bin/tar: .cl.selector: Cannot stat: No such file or directory
/bin/tar: Error is not recoverable: exiting now

lstat('/backups/srv2/admin.119501.rCZEGOURsL9UvpeXGmXqF6b2qsUilUka/Owiox0jRyKFQMB6QHZyN2pf46yOHQeSo/usernamehere/backup/home.tar.zst'): No such file or directory

There files are already owned by the user:
Code: 
-rw-r--r--   1 usernamehere usernamehere  456 Oct  6  2022 .bash_history
-rw-r--r--   1 usernamehere usernamehere  220 Dec 30  2012 .bash_logout
-rw-r--r--   1 usernamehere usernamehere  214 Oct 20  2022 .bash_profile

Most back-ups are running correct. The permissions of the files in the correct back-ups are the same as the files of the failed back-ups.

I also noticed this file in the userfolder of the failed back-ups:
Code: 
-rw-r--r--   1 usernamehere usernamehere    0 Jun 26 20:01 -T
 
I removed the -T file. And the back-ups are running again. Any idea how this file is created?


Edit:
Turns out this was caused by faulty user cronjobs.
 
Last edited:
jamgames2 said:
@ps4all
"Update All" button will not update system package ( yum -y updata ).

Version 1.650 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com


maybe they just manual click update button of system package ( without reading ).
Click to expand...
Yea, i just got it confirmed from two of them... they indeed usually click Update All and click every green button shown after running Update All.

The reasons why they click that is because else they receive e-mails over and over again mentioning the system updates beïng available and they are affraid of beïng vulnerable when they don't update right away. That it might cause issues with certain things, is blamed on DirectAdmin.

Anyway... it was just a suggestion, just as I suggested those people to move over towards Fastpanel if they hate receiving the e-mails about new system packages beïng available.
 
fln said:
CLI and GUI behaves the same, doing da build versions would report updates to imagic PHP extension:

Code: 
# da build versions
...
Latest version of imagick PHP 7.4 extension: 3.7.0
Installed version of imagick PHP 7.4 extension: 3.7.0 (linked with old ImageMagick)

imagick PHP 7.4 extension 3.7.0 (linked with old ImageMagick) to 3.7.0 update is available.
...
If you want to update all the available versions run: /usr/local/directadmin/custombuild/build update_versions

Runing da build update_versions would actually update imagic PHP extension if needed:

Code: 
# da build update_versions
...
Updating imagick PHP 7.4 extension
...

Note: da build ... is the same as ./build ... without the need to go into custombuild directory (since da command is available in the path from any directory).
Click to expand...

Actually, it doesnt:

da build versions

Latest version of ImageMagick: 7.1.1-11
Installed version of ImageMagick: 7.1.0-57

ImageMagick 7.1.0-57 to 7.1.1-11 update is available.

....

Latest version of PHP 7.4: 7.4.33
Installed version of PHP 7.4: 7.4.33

Latest version of PHP 8.1: 8.1.19
Installed version of PHP 8.1: 8.1.19

Latest version of PHP 8.2: 8.2.6
Installed version of PHP 8.2: 8.2.6

....

Latest version of Imagick PHP 8.2 extension: 3.7.0
Installed version of Imagick PHP 8.2 extension: 3.7.0

Latest version of Imagick PHP 8.1 extension: 3.7.0
Installed version of Imagick PHP 8.1 extension: 3.7.0

Latest version of Imagick PHP 7.4 extension: 3.7.0
Installed version of Imagick PHP 7.4 extension: 3.7.0
Click to expand...

After running da build update_versions:

Latest version of Imagick PHP 8.2 extension: 3.7.0
Installed version of Imagick PHP 8.2 extension: 3.7.0 (linked with old ImageMagick)

Imagick PHP 8.2 extension 3.7.0 (linked with old ImageMagick) to 3.7.0 update is available.

Latest version of Imagick PHP 8.1 extension: 3.7.0
Installed version of Imagick PHP 8.1 extension: 3.7.0 (linked with old ImageMagick)

Imagick PHP 8.1 extension 3.7.0 (linked with old ImageMagick) to 3.7.0 update is available.

Latest version of Imagick PHP 7.4 extension: 3.7.0
Installed version of Imagick PHP 7.4 extension: 3.7.0 (linked with old ImageMagick)

Imagick PHP 7.4 extension 3.7.0 (linked with old ImageMagick) to 3.7.0 update is available.
Click to expand...

So custombuild is not updating PHP when ImageMagick is being updates, causing these errors.

PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1808 but version 1809 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1808 but version 1809 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1808 but version 1809 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
PHP Warning: Version warning: Imagick was compiled against ImageMagick version 1808 but version 1809 is loaded. Imagick will run but may behave surprisingly in Unknown on line 0
Click to expand...
 
hi everyone, quick update, we have released a hot-fix adressing two issues:
  • on some systems updating backup cron jobs could fail with error message generateCrontab: Bad file descriptor, thanks @Yoshua for this thread.
  • IP restricted login URLs could lead to infinite Evolution reload loop, issue reported in tickets.
 
ps4all said:
Would be awesome to have an option to supress (disable) "System updates" via options.conf or directadmin.conf.
Click to expand...
This please, or find a way to check if packages are set to kept back for updating.... Had to disable daily email for updates because of this stupid addition.
 
LawsHosting said:
This please, or find a way to check if packages are set to kept back for updating.... Had to disable daily email for updates because of this stupid addition.
Click to expand...
The best thing to do is just make System Updates optional, simply, osupdates = true/false.

No detours, ifs, buts and hassle. I know plenty of people who rent a server with DirectAdmin on it and have it customized. A simple apt-mark hold (Debian) is of little use because that also means that any packages that depend on something can get the necessary issues.

Anyway, I don't think it's up to DA to determine whether someone installs OS updates or not and/or force people to do so. Now it's OS updates but what will it be tomorrow, OS upgrades? I think it's up to the server owner to decide whether to install updates, but a noob clicks on all shown buttons with all the risks and consequences that entails. So to make it easy it seems way better to cover that part by making OS updates optional by (for example) "osupdates = true/false".
 
LawsHosting said:
This please, or find a way to check if packages are set to kept back for updating.... Had to disable daily email for updates because of this stupid addition.
Click to expand...
You can run the command:

curl $(/usr/local/directadmin/directadmin api-url)/api/custombuild/updates

To get a list of what Custombuild patches are needing an update. This outputs the information in JSON.

Then you can parse that JSON and exclude what you don't want to be notified about. System package updates will have a ['name'] == System packages value.

This is what I do. Granted, it requires some self-scripting, but this is actually how I prefer to do thing. I just want DirectAdmin (or any control panel) to provide me tools from which I can glean the information I want. This gives me more control.
 
sparek said:
..........................
Click to expand...
Which still doesn't supress the message about OS Updates, doesn't hide the update button from DA.
By the way, your method doesn't show which packages (OS Updates) are available... so that trick doesn't really help either if it's about updating packages which are under OS Updates (repositories (Yum/Apt etc)).
 
You must log in or register to reply here.
Back
Top