DirectAdmin v1.671

A new build 40d857591b4a0044cafccc0ae21e54692aa43dc6 is relased, it only adds an additional step to make sure /etc/csf/csf.pignore is updated. This avoids the false-positive notifications as reported by @JosKlever.
I've installed this build but the "Suspicious process running" still are being sent. (on multiple servers)
 
@exlhost well we could update PHP versions for stable, but I do not see a compelling reason to release an update with just the version bumps. The stable will get the latest software once it moves to 1.671.

@zenowebdev, the DA update script only updates /etc/csf/csf.pignore if CSF is enabled in the /usr/local/directadmin/custombuild/options.conf file. If options.conf has csf=no but CSF is actually running, DA will not touch the csf.pignore file. To check if the /etc/csf/csf.pignore was automatically updated, please compare it against the /usr/local/directadmin/custombuild/configure/csf.pignore file.
 
@fln

I understand that, but not everyone wants and can upgrade to current 1,671 yet. And on stable the security software PHP updates are not available. So they are at risk. What you think about that?, only if you adjust them in the custom versions you could update them which is allot of work if you got allot of boxes. Major changes have been made in version 1.671. DirectAdmin extended for whmcs no longer works and needs to be drastically adjusted on API level which may take another month or so. Why are these changes not reflected in the changelog?
 
Last edited:
DirectAdmin extended for whmcs no longer works and needs to be drastically adjusted on API level which may take another month or so.
We moved away from DA Extended some time back, because it was always trying to catch up with the DA features, and for certain functionality it simply couldn't work (e.g. lack of API endpoints). With the ability to customize the DA menus etc, we found it much simpler to provide a one-click-login from the WHMCS client area into DA, for a much better user experience managing their accounts.
 
We have not yet received any reports that latest upgrade broke external integrations, except for a couple reports about completely custom integration. There are no drastic changes on the API level in this release. The only are of change is the login-keys management endpoints, they are ported to the new code-base so there are some changes but they are only for the corner-cases.

One know issue that will get fixed in DA 1.672 (and backported to DA 1.671 prior to releasing it to stable) is to make CMD_LOGIN_KEYS accept request encoded in multipart/form-data content type. It is usually used only when transferring files, but apparently some integrations try posing simple FORM data using this encoding. Maybe the mentioned plugin tripped on this issue as well.

Such changes are not mentioned in the change-log because they were not expected to affect anyone. Once we discover that some bug or quirk was abused as a feature we usually back-port it to the new code base.
 
Such changes are not mentioned in the change-log because they were not expected to affect anyone.
I think maybe you under-estimate all the weird things people (like me) do. I would be grateful for inclusion of *all* technical changes between versions. It simplifies troubleshooting greatly when these changes actually cause issues, and since you already know what changes you're making, it doesn't cost much to include information about them.
 
We do our best to document all the breaking changes. However, we often find out about them not because we did them deliberately.

For example, in this release, the login-key management endpoints were migrated from the old codebase (written in one programming language, using a handwritten http library) to the new codebase (written in a different programming language, using a standard http library). The new codebase with modern http library is already being used for more than three years for various DA endpoints (even quite important ones like CMD_API_DATABASES, etc.). And we have never received a report that someone is using multipart/form-data content encoding for requests that does not upload files.

But apparently, when login-key management endpoints were migrated it revealed, that someone was abusing the quirk of the old http library in this way. So the change when we used the new library was made three years ago, yet the problem manifested after a long time with completely unrelated changes.

Quick demo of the side-effects:

Code:
# da update stable
# time curl -s "$(da api-url)/CMD_LOGIN_KEYS?json=yes" --data-raw 'action=create&type=key&keyname=test&key=AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL&key2=AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL&never_expires=yes'
{
    "result": "AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL",
    "success": "Key Created. Take note of it's value and keep it safe."
}

real    0m0.251s
user    0m0.019s
sys    0m0.009s
# time curl -s "$(da api-url)/CMD_LOGIN_KEYS?json=yes" --data-raw 'select1=test&delete=Delete&action=select'
{
    "result": "",
    "success": "Key(s) deleted"
}

real    0m0.248s
user    0m0.019s
sys    0m0.008s

Code:
# da update current
# time curl -s "$(da api-url)/CMD_LOGIN_KEYS?json=yes" --data-raw 'action=create&type=key&keyname=test&key=AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL&key2=AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL&never_expires=yes'
{"result":"AzYhfiFjlpcDtGMSFPA0SxnbniuF7gVL","success":"Key Created. Take note of it's value and keep it safe."}
real    0m0.180s
user    0m0.024s
sys    0m0.000s
# time curl -s "$(da api-url)/CMD_LOGIN_KEYS?json=yes" --data-raw 'select1=test&delete=Delete&action=select'
{"result":"","success":"Key(s) deleted"}
real    0m0.117s
user    0m0.024s
sys    0m0.006s

The new codebase is 1.5x–2x times faster. Trying to write out all the things it does differently is not trivial. For example, even in the requests above, it is easy to spot a difference. The new codebase outputs JSON in compact form. If someone was expecting to find the result string on the second line of the response, their application would break. The result is now always single-line, so there is no "second line." This is a good example of how a poor API client could depend on quirks of the old http library.
 
Why every time the skin is updated it looks worst? Like the old "hybrid" theme was fantastic and it now looks bland and messy and never liked refreshed layout, is all over the place.
 
An update is released with a fix for two regressions:
  • Creating login keys via API will start accepting simple form data encoded as multipart/form-data.
  • Creating login URLs will accept a comma (, symbol) as a separator for multiple IP restrictions.
 
@ericosman, the latest patch for legacy API compatibility can not affect this. Do you mean it happened after updating DA 1.670 (stable) to 1.671 (current)?
 
In this case please open a support ticket. Thanks.
 
For example, in this release, the login-key management endpoints were migrated from the old codebase (written in one programming language, using a handwritten http library) to the new codebase (written in a different programming language, using a standard http library).
Can you verify/confirm that this migration broke CMD_API_LOGIN_KEYS functionality to create a one_time_url?

Code:
# Trying to create a single-login URL seems to fail:

POST https://da.example.com:2222/CMD_API_LOGIN_KEYS
  action=create
  type=one_time_url
  max_uses=>1
  clear_key=yes
  select_allow0=ALL_USER
  allow_html=yes
  passwd=password

RESULT:
    Error: Unknown action
 
@mcormick, there is too little information in your post for a definitive answer. Your example does not specify how you encode the parameters that are being sent to the server.

If your integration used to send the data encoded as multipart/form-data instead of the expected application/x-www-form-urlencoded then latest hot-fix release will fix your issue without the need to change the integration code.
 
@mcormick, there is too little information in your post for a definitive answer. Your example does not specify how you encode the parameters that are being sent to the server.
Parameters are sent to the server as application/x-www-form-urlencoded, and because the response is "Unknown action", it seems the API recognizes the posted data, because it doesn't say "action is missing", nor "Unauthorized". And in your changelog I saw reference to action=select being "Unknown action", hence why I raised this. Our call works just fine for 1.670.
 
Unknown action is the same as missing action. Your example works fine in DA 1.671:

Code:
# da v
DirectAdmin v.1.671 3bf563cd170b32b0ce8a9d48f4eafa8be149f59c

# curl -X POST \
    -d action=create \
    -d type=one_time_url \
    -d 'max_uses=>1' \
    -d 'clear_key=yes' \
    -d 'select_allow0=ALL_USER' \
    -d 'allow_html=yes' \
    -d 'passwd=password' \
    "$(da api-url)/CMD_API_LOGIN_KEYS"
details=https%3A%2F%2Fserver.example.com%3A2222%2Fapi%2Flogin%2Furl%3Fkey%3Drffe4P-ix3FJN6rJ5z4m-oudnAg8EtWn&error=0&text=One-Time+Login+URL+Created


# curl -X POST \
    -d action=create
    -d type=one_time_url
    -d 'max_uses=>1'
    -d 'clear_key=yes'
    -d 'select_allow0=ALL_USER'
    -d 'allow_html=yes'
    -d 'passwd=password' \
    "$(da api-url)/CMD_API_LOGIN_KEYS?json=yes"
{"extended":"true","result":"https://server.example.com:2222/api/login/url?key=B81ObuhCLRAdrLv23Mh5VIWh4JNBeiAX","success":"One-Time Login URL Created"}

Prior to the hot-fix replacing the curl -d parameter with -F (to force multipart/form-data content encoding) would not work and would return action is missing error.
 
@AU_Chris please open a support ticket. We need more details to investigate it further.
 
Back
Top