Directadmin Docs

Version 1.53.2

Released: 2018-07-16

Check for mysql host.err, in addition to host.name.err for bfm scanning new

Relating to:

BFM: Added mysql failed auth checking

The internal DA default is to use something like:

brute_force_mysql_log=/var/lib/mysql/host.name.com.err

(path varies per OS)

but the default for log-error on some versions of MySQL/MariaDB is:

/var/lib/mysql/host.err

where the short form is used.

If brute_force_mysql_log is added to your directadmin.conf, this overrides everything and uses whatever you set.

As before the |HOSTNAME| variable can be used, which inserts the "servername=" value from the directadmin.conf into the value.

Fix:

If the default internal brute_force_mysql_log is used, then the timestamps for both host.name.com.err and host.err will be checked.

If one does not exist, then the timestamp will be 0...

The largest timestamp seen will be used as the log to parse.

====

Note, some MySQL/MariaDB versions require the blank entry to be added to the /etc/my.cnf in the [mysqld] section, eg:

log-error=

without any value, and this forces the default, to be logged to, eg:

/var/lib/mysql/host.err

====

This fix is mainly only added to allow for a static /etc/my.cnf used across many different boxes, but to still use a dynamic err file...

and such that DA will pick up the variable name for parsing.

last_login to track email logins new

The da-popb4smtp binary now has extra code to store the last login for each account.

For virtual email accounts, stored here:

/etc/virtual/domain.com/last_login/user

for DA email logins (eg: login to /roundube as "user" without @domain), it's logged here:

/usr/local/directadmin/data/users/username/last_login

The format of the last_login file is fairly basic, a timestamp, followed by data, eg:

when=1530843760&ip=127.0.0.1

During the backup/restore, this file will fall under the "E-Mail Data" category.

Enhanced skin

The last login info (date and IP) will show up in the "hover-over usage popup" window.

Go to the email page, and hover your mouse over the usage for a given account.

If they've logged in recently, the "Last Login" and "Last Login IP" will be in the popup.

Json will have the data in the same page:

emails{

#{

usage{

last_login{

ip and when

where "when" will be the unix timestamp.

DISABLED BY DEFAULT

The directadmin binary will not show this data by default until caching and fast reading of the data is implemented.

The internal default is:

email_show_last_login=0

to enable it, add:

email_show_last_login=1

to the directadmin.conf and restart DA.

Note that the da-popb4smtp will always log the last_login, even if this settings it off.

The setting only applies to directadmin and the dataskq.

FileManager to check for binary data before showing edit text new

When editing a file, DA shows the "Edit" button, solely based on the mime type via file extension.

However, there are cases, such as dovecot.index.log where this file is binary, and should not be edited.

When the action=edit is called on a file, the "file" program is run as the User to try and figure out if the type returned is binary and should not be edited.

directadmin.conf internal default:

fm_allow_binary_edit=0

To allow binary files to be edited (bypass the check), add:

fm_allow_binary_edit=1

and restart DA.

=================

ERROR from the error.log:

2018:09:07-12:16:34: User bob tried to edit '/home/user/domains/domain.com/public_html/file.php', but the file is not editable due to type 'data'

or output to User:

File is not editable due to type 'data'

Quick json directory tree for CMD_FILE_MANAGER new

Sample call:

CMD_FILE_MANAGER?action=tree&json=yes&path=/

outputs (for example, heavily redacted):

[
    { "path": "/Maildir", "dirs": 0, "files": 1, "files_size": 4096 },
    { "path": "/backups", "dirs": 0, "files": 7, "files_size": 963448607 },
    { "path": "/", "dirs": 2, "files": 13, "files_size": 48422568 }
]

The output is not stored before sending.

The recursive directory traversal spits out the information the moment it's got it, making this the fastest way to get a directory tree.

The files_size is the sum of all file-size totals in this directory (not sub directories), in bytes.

CMD_SKINS: ability to change directadmin.conf docsroot to affect login page (SKINS)(LANG) new

The evolution skin comes with a login.html built in.

DirectAdmin can only ever show 1 login page, so it checks if the directadmin.conf docsroot value has a login.html associated with it.

The feature adds a "Set Global" button to the CMD_SKINS table, but only for Admin accounts.

You can see the current directadmin.conf docsroot at the bottom eg:

Global Document Root./data/skins/enhanced

=====================

SKINS

reseller/skins.html

Changed the lower part of the page to show:

<table>
<tr><td>|LANG_CURRENTLY_USING|</td><td><b>|SKIN|</b></td></tr>
<tr title='|LANG_FOR_LOGIN_PAGE|'><td>|LANG_GLOBLAL_DOCSROOT|</td><td><b>|GLOBAL_DOCSROOT|</b></td></tr>
</table>
LANG

lang/en/reseller/skins.html

LANG_GLOBLAL_DOCSROOT=Global Document Root

LANG_FOR_LOGIN_PAGE=for login page and defaults

JSON

New array called "settings" with a value:

"global_docsroot": "./data/skins/enhanced"

DEVELOPERS

Note the reset command:

CMD_SKINS?reset=yes

sets your user.conf back to the directadmin.conf docsroots, so you'll want to make sure the skin is fully functional and trusted before clicking this option.

Else, if you end up with a broken skin state, you cannot reset it back to enhanced (for example) via that command,

and would then need to manually edit your user.conf to change the docsroot and skin values.

missing DS records of sub-zone to parent fixed

When adding a sub-domain zone on the server, where the parent domain does exist, there was a bug where in some cases, the parsing of the dsset-sub.zone.com. file was broken because DA was looking for:

" DS "

when in some cases, the string was:

" DS"

where a trailing tab was present, rather than a space.

This appears to be controlled by the length of the sub-zone name (not confirmed), but once it was realized the trailing character was a tab, the DS value was able to be parsed, and inserted into the parent zone.

:fail: and :blackhole: not being allowed in forwarders fixed

Bug introduced with this change:

Prevent duplicate forwarder values

that incorrectly blocked the use of :fail: or :blackhole:

Restore with Local Namervers: set NS records for restored Reseller fixed

Bug where, when using the "Restore with Local NameServers" checkbox enabled, and when restoring a Reseller, the NS records in their zone did not respect the setting.

The previous NS records were still restored. Does not apply to restoring a User, which does respect the setting.

The ns1/ns2 values in the:

Reseller Level -> Nameservers

will still be restored to the old value, as it does not affect the "restoring" of accounts, as per the wording of the checkbox.

If there is demand, we can change it to also match the Admin account's ns1/ns2 values.

Last Updated: