DirectAdmin Docs
Search K

Appearance

Version 1.62.8 ​

Released: 2021-09-21

Adding missing system DB Users to all databases new ​

If, for whatever reason, the system account is missing from MySQL, re-adding it and granting to all DBs manually can be tricky.

This feature allows root to run one command which checks the databases of all User accounts, or one User, to check all DBs and re-add the system accounts as needed.

T34405

Removed in DirectAdmin 1.665.

Drop directadmin suid bit support update ​

Starting this version directadmin will no longer support having suid bit set. On update suid bit will be dropped and directadmin will always run under user it was started.

This feature essentially removes functionality based around /root/.suid_directadmin introduced here

Backwards compatibility for cli call directadmin --DocumentRoot were added.

Brute force performance improvements update ​

Brute force counters feature was upgraded from file based counters to in-memory based request counters. This should reduce the I/O on busy servers where brute-force protection is turned on.

CloudLinux: update DocumentRoot.cache.json after each httpd.conf write update ​

Relating to the existing DocumentRoot.cache.json cache documented here

which was meant for the now deprecated suid call:

./directadmin --DocumentRoot

This change will keep the DocumentRoot.cache.json file updated via task.queue updates after each write to the User's httpd.conf

The file lives at:

/usr/local/directadmin/data/users/fred/DocumentRoot.cache.json

and now has the User's group 640 set, eg:

-rw-r-----   1 diradmin fred    817 Sep 16 16:00 DocumentRoot.cache.json

so the need for the suid binary is no longer needed, as the json file can be read directly.

task.queue ​

2 new task.queue calls are used by this feature, can be triggered manually if needed:

echo "action=cache&value=document_root" >> /usr/local/directadmin/data/task.queue
echo "action=cache&value=document_root&user=fred" >> /usr/local/directadmin/data/task.queue

Where the user option rewrites the DocumentRoot.cache.json for just that User. Absence of the user option rewrite the DocumentRoot.cache.json files for all DA Users.

Requirements ​

This task.queue write will trigger if custombuild/options.conf has:

cloudlinux=yes

You can accomplish the same thing by creating:

/usr/local/directadmin/scripts/custom/user_httpd_write_post/document_root_cache.sh

with code:

bash
#!/bin/sh
echo "action=cache&value=document_root&user=$username" >> /usr/local/directadmin/data/task.queue
exit 0

and set the script to chmod 755.

API call for listing all subdomain document roots for all users update ​

Already existing CMD_API_DOMAIN command was extended to have a new action document_root_all to list all web-server document root for all users.

An API call to .../CMD_API_DOMAIN?json=yes&action=document_root_all would return the same data as a CLI command directadmin --DocumentRoot executed by root account would do.

This new action is available for admin accounts only.

All integrations relying on directadmin --DocumentRoot is encouraged to switch to using the new API call. CLI argument will be deprecated and removed in the future.

CGroup: restore User: sets default to Reseller if user.conf blank fix ​

If a local Reseller with imposed CGroup limits is trying to restore a User from a remote box which does not have any limits set, the restore might throw an error similar to: Cannot create user fred: cgroup error: CPUQuota is missing

For manual/API User creation, this behavior will be unchanged (to remind the Reseller to set a limit). However for a Restore, a workaround has been added to simply set the Reseller's default value for those limits to allow the User to be restored. The limits can be reduced later, as needed.

T34312

show_all_users_cache_extra_vars: not showing on Reseller List Users fix ​

Any of the extra variables from the CMD_USER_SHOW, if not using the cache would result in a blank field: date_created=""

this is because it was taken from the cache file, whose container was not filled in this mode.

T34558

PhpMyAdmin: one-click SSO can be slow with large information_schema fix ​

When a User uses the one-click single-signon to phpMyAdmin, it creates the internal da_sso_* account name for login. The "username" does not have privileges on views, etc, if the definer is that da_sso_* username. There is a cleanup task which hunts for the da_sso_* definers and swaps as needed, documented here

On larger systems where the information_schema.* is large (specifically .views in the report), the query to obtain this list can be quite slow.

Fix: Upon the SSO click, instead of doing the cleanup in realtime, push the cleanup request to the task.queue for cleanup ~1 minute later. The cleanup would remove old da_sso accounts, and swap any incorrect definers. As this new da_sso account likely has not yet created any views, this is not critical to run right away.

There is also a call anyway with the nightly tally, but this will ensure that the definers are swapped over more quickly to avoid confusion.

Custom Hook for CMD_API_EXEC: api_exec_pre.sh fix ​

Custom hook for CMD_API_EXEC:

/usr/local/directadmin/scripts/custom/api_exec_pre/yourhook.sh

Needed because the all_pre.sh $command is filled with /CMD_API_EXEC, but the POSTed command= value contains the binary call. Thus the all_pre.sh has no way of knowing what the POSTed command is, as it's always filled with /CMD_API_EXEC

T34589

Update to set data/lang permissions to diradmin fix ​

The gettext .po files might be chowned to root. DA needs to convert them to .mo files via /usr/bin/msgfmt (from the gettext package), but runs as diradmin. The update will reset /usr/local/directadmin/data/lang and everything below it to diradmin.

All dirs to 755, files 644.

2021:08:22-13:06:23: msgmt error:

without any actual message.

T34840

Login system security Improvements (SECURITY) fix ​

Fix to address improved security for the login system. We'll not be disclosing further details on the issue, but recommend updating to get this fix.