DirectAdmin v1.662

Thanks for the feedback. The change in forwarders configuration intentional (requiring to press add button) but not entirely obvious. For the time being we will rollback to not require clicking add button. In the next release we are planning to do a bigger upgrade on forwarders page and aim to make it more intuitive and easier to use.

An update is released now to revert it to the old behaviour.
@gate2vn, it is intented for FM to fully log user out. File Manager is a separate stand alone application and it does not have the impersonation (login-as) logic built-in. Because in File Manager there is no clear indication that user at the moment is in the "impersonation" mode (in Evo we have back top bar as an indicator) we perform a full-logout to prevent admin or reseller accidentally leaving active session.
@JosKlever thanks for reporting the login key log issue. It is not directly related to this release and will be fixed with the next release.
 
Is it possible the API endpoint, for creating a database (CMD_API_DATABASES), is affected by this release? We're getting a 500 with payload details=Unknown+action&error=1&text=Invalid+values
Last monday it was working like a charm, yesterday our Direct Admin was automatically updated from 1.661 to 1.662
 
  • Like
Reactions: fln
@witkamp.gerrit Legacy databases API are now using new DB management engine. The new engine is as close as possible to the old API for backwards compatibility, but there might be subtle changes if API was used in a way we did not expect. Old engine was less strict when validating requests which allowed slight API abuse.

We have already made new engine less strict by allowing missing content-type header for POST requests in DA 1.663. Could you please check if switching to beta release channel fixes the issue? If it does we would add these changes to the 1.662 release.
 
Oh...
After update to 662 from 661 almost all of our api commands do not work, empty log in debug mode and an error is returned {"details":"Unauthorized","text":"Not logged in","error":"1"}.
 
@Access_Denied, this is a different issue. All other CMD_.. API endpoints are still processed by the old engine, only the databases management related endpoints are transferred.

Could you please open a ticket so we could get more information about the way you use API?
 
Searching for potential differences in old DB management API, we found that engine used in old DA versions was not strict about expected request HTTP method. For example doing POST /CMD_API_DATABASES to list databases without any action.

We are not sure if this would solve you issue so would be good to check it out. An update is released to the beta release channel where new database API engine is relaxed to support POST requests for actions where GET should be used. @witkamp.gerrit could you check if doing da update beta fixes the issue for you (without changing release channel to beta DA will revert back to the latest commit of your selected release channel after ~30mins). If this was the root cause for your integration we would release it to current release channel as well.
 
Last edited:
@Access_Denied, resolved this issue internally. Root cause of the problem was API client using HTTP basic authentication where username and password was encoded using base64 in no padding mode. New DA version is more strict about it and requires credentials to be encoded in standard base64 encoding mode (with padding).
An update is release to make database management legacy API more lax and backwards compatible. It should fix installatron plugin integration.
 
fln said:
@witkamp.gerrit Legacy databases API are now using new DB management engine. The new engine is as close as possible to the old API for backwards compatibility, but there might be subtle changes if API was used in a way we did not expect. Old engine was less strict when validating requests which allowed slight API abuse.

We have already made new engine less strict by allowing missing content-type header for POST requests in DA 1.663. Could you please check if switching to beta release channel fixes the issue? If it does we would add these changes to the 1.662 release.
Click to expand...
Hi, we're doing a HTTP POST, so I guess that shouldn't be the issue. But we don't add a Content-Type header, so maybe that could be the cause. Will try to add this one. Just to prevent some trial and error, which value of the header do you guys expect?
 
@witkamp.gerrit, before making any changes just try upgrading DA to the latest hot-fix release in the current release channel. Changes there might fix the problem.
 
fln said:
@witkamp.gerrit, before making any changes just try upgrading DA to the latest hot-fix release in the current release channel. Changes there might fix the problem.
Click to expand...
Hi, just updated to 1.662 (e07e6c66152ffcb0d060aac6a2e4b21457e09608). We still got a HTTP 500, but with another error:
details=Unable+to+connect+to+the+database&error=1&text=An+Error+has+occurred
 
Such errors should provide more information in the service log journalctl -u directadmin or journalctl -u directadmin -f for live log stream.
 
fln said:
Such errors should provide more information in the service log journalctl -u directadmin or journalctl -u directadmin -f for live log stream.
Click to expand...
Is it possible to see the log using the Control Panel itself? We don't have access to this log file using cli
 
No, system journal is not visible via web interface. It is very likely that without root access to the server you will not be able to resolve this issue. I would recommend opening a support ticket and we will help you out.
 
Since my server updated from 1.661 to 1.662, i keep getting SMTP SSL errors when trying to send emails..
i have to run rewrite_confs and restart the server to resolve the issue, but it comes back after a day or so..
 
We reached out to our hosting party for the journal log:
getting databases list error=Error 1615 (HY000): Prepared statement needs to be re-prepared req-uri=/CMD_API_DATABASES req-user=foo|bar

Futhermore, when using /api/db-manage/create-db-with-user, we got the following eror
{"message":"unexpected error, please check server error log for more details","type":"INTERNAL_ERROR"}

The logfile System Messages from the webinterface shows me:
Apr 25 16:56:03 foo directadmin[123]: creating database with user collation= database=foo_bar dbuser=foo_bar error=Error 1615 (HY000): Prepared statement needs to be re-prepared hostPatterns=[localhost] privs={true true true true true true true true true true true true true true true true true true} req-uri=/api/db-manage/create-db-with-user req-user=foo|bar

Executing the API-call api/db-manage/create-db works as expected, so it seems like creating the user is going wrong.

Maybe related with below?

Troubleshooting | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com
 
Last edited:
Regarding the new API increasing the table_definition_cache (equal or higher than table_open_cache) did the trick.
The legacy API returns an empty text/plain response and no db created.

It seems like the CMD_API_DB_USER is also affected, which gives the error details=The+database+%27%27+does+not+belong+to+you&error=1&text=An+Error+has+occurred
 
Last edited:
You must log in or register to reply here.
Back
Top