DirectAdmin v1.672

it looks like DirectAdmin uses 164.5 CPU in the first image. It may be that DA becomes heavier and also uses more resources. How many cores does the VPS have?
 
Active8 said:
Updated several servers here and did not noticed this, maybe its an combination of running services ?
Click to expand...
I'm not sure, it report resource usage from the user of my customer. ( And after got report from CSF, pass hourly, CGroup still report high resource usage). I do many thing to resolve this issued.... Like update OS, Reboot Server, ..etc..

Maybe outdate some of linux library ( Only 1-2 month ). Nevermine It still working. 😅
 
exlhost said:
it looks like DirectAdmin uses 164.5 CPU in the first image. It may be that DA becomes heavier and also uses more resources. How many cores does the VPS have?
Click to expand...
Usually at least 4 to 8 cores, depending.

The thing that gets me most, and why I posted it here that all was well on all those machine and only updating DA (and therefore the custom builds, of course) makes the machines run high.
 
If DA is using a high CPU, run DA in debug mode for 30 minutes or so, and open 2 SSH sessions, one to debug DA and the other for top...... When DA uses a high CPU, switch to the debug session to see what DA is processing........🤷🏻‍♂️
 
The button add user packages if none have been created yet does not work. you can click whatever you want nothing happens.

add.jpg
 
  • Like
Reactions: fln
exlhost said:
The button add user packages if none have been created yet does not work. you can click whatever you want nothing happens.

View attachment 8743
Click to expand...
Just tested it under new Reseller and can confirm the same situation on DA 1.672.
Downgraded to version 1.671 - it works fine.
I will open internal report to developers to check it closer.
 
I ran into a small issue when installing a new DirectAdmin server, it seems that the symlink for spamd.service is not being created:

OS: Ubuntu 24.04.1 LTS
DA: directadmin current v1.672 f9514c463b99b9d746cf7f35b22a1a05c998b500

Issue has been fixed by creating the symlink manually:

Bash: 
root@server:~# systemctl status spamd
Unit spamd.service could not be found.

root@server:/etc/systemd/system# ln -s /etc/systemd/system/spamassassin.service spamd.service

root@server:/etc/systemd/system# systemctl daemon-reload

root@server:/etc/systemd/system# systemctl start spamd

root@server:/etc/systemd/system# systemctl status spamd
● spamassassin.service - Spamassassin daemon
     Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; preset: enabled)
 
fln said:
Thanks for the feedback. We have pushed out an update with the following changes:
  • Removed the user impersonation bar from File Manager. We expect it to be introduced in the upcoming releases, but it is too early for it in this release. Thanks @JosKlever.
  • Fixed styling of user impersonation bar user selector.
  • Added a temporary workaround for the ConfigServer plugins to continue working without problems. We have reached out to the developers and got confirmation it will be improved from their side as well.
The root cause for the ConfigServer plugins failing to load was a check inside the plugin code that checks for the parent process name. Because of the changes in how plugin processes are started, the name is not the same as before and caused the plugins to stop working. The fix from the plugin side is just to stop checking the name of the parent process. The fix from our side is to continue using the same process name as before.
Click to expand...
This was the fix, thanks.
 
SanderJ said:
I ran into a small issue when installing a new DirectAdmin server, it seems that the symlink for spamd.service is not being created:

OS: Ubuntu 24.04.1 LTS
DA: directadmin current v1.672 f9514c463b99b9d746cf7f35b22a1a05c998b500

Issue has been fixed by creating the symlink manually:

Bash: 
root@server:~# systemctl status spamd
Unit spamd.service could not be found.

root@server:/etc/systemd/system# ln -s /etc/systemd/system/spamassassin.service spamd.service

root@server:/etc/systemd/system# systemctl daemon-reload

root@server:/etc/systemd/system# systemctl start spamd

root@server:/etc/systemd/system# systemctl status spamd
● spamassassin.service - Spamassassin daemon
     Loaded: loaded (/etc/systemd/system/spamassassin.service; enabled; preset: enabled)
Click to expand...
We have the report to our developers already opened regarding this issue.
I opened it several days ago.
Also the problem does not happen only on Ubuntu 24 OS, but I suppose on other OSs too. At least I was able to reproduce it on the server with AlamaLinux 9.X OS.
 
The 2FA check box to indicate that the device is trusted for 30 days gives an incorrect value of 0 days instead of 30.
 
  • Like
Reactions: fln
exlhost said:
The 2FA check box to indicate that the device is trusted for 30 days gives an incorrect value of 0 days instead of 30.
Click to expand...
Just tested it on my test DA 1.672 and can confirm the same small issue there.
Downgraded to version 1.671 - it works fine.
I opened internal report to developers to get it corrected.
 
Thanks @exlhost. An update is released with the following fixes:
  • Fixed the button to create a new package.
  • Fixed the number of days to remember the 2FA secret on the login page.
  • Fixed a bug in the FileManager tree view. Clicking on a new directory used to expand not the latest visited directory but a previous one.
 
Hostmavi said:
Hi ;
the new feature
Block browser content sniffing
Added a security feature to block content sniffing by the browsers and trust the Content-Type header sent by the server.

i can't find any Setting for this feature or Setting for enable it ??
how it's works

the was way to add it do we need this ??
Click to expand...
You can see the difference here:

- for DA 1.672:
Bash: 
[root@ser2 ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/
HTTP/2 200
accept-ranges: bytes
cache-control: no-cache
content-type: text/html; charset=utf-8
cross-origin-resource-policy: same-origin
etag: "137800/173...726/3317"
last-modified: Wed, 18 Dec 2024 07:58:46 GMT
vary: Origin
vary: Accept-Encoding
-----
x-content-type-options: nosniff       <------------
-----
x-frame-options: sameorigin
content-length: 3317
date: Sat, 21 Dec 2024 20:12:45 GMT

[root@server2 ~]#

- but for DA version 1.671 or lower version that x-content-type-options: nosniff line is absent:
Bash: 
[root@ser ~]# curl -IL https://ser.mytest.dasup.ua:2222/evo/
HTTP/2 200
accept-ranges: bytes
cache-control: no-cache
content-type: text/html; charset=utf-8
cross-origin-resource-policy: same-origin
etag: "165400/173...053/3148"
last-modified: Sat, 21 Dec 2024 20:14:13 GMT
vary: Origin
vary: Accept-Encoding
x-frame-options: sameorigin
content-length: 3148
date: Sat, 21 Dec 2024 20:16:03 GMT

[root@ser ~]#
 
You must log in or register to reply here.
Back
Top