DirectAdmin 1.666

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,071
We are happy to announce the release of DirectAdmin 1.666.

This release brings new TLS Server Certificate page, Debian 13 and Ubuntu 24 support, compatibility with MySQL partial_revokes mode, and various smaller improvements.

A full release change log is here:

DirectAdmin 1.666​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
An update is released with two fixes:
  • Fix for manual certificate upload button in Evolution
  • Fix for database disk usage reporting in Enhanced, thanks @Richpark, for reporting
 
gate2vn said:
No delete button in DNS Administration? Tested in both 1.665 and 1.666
Click to expand...
"Delete" button is there - in the left bottom conner on your screenshot. But yes, it does not look great. I will check it with developers.
 
I see that one_click_pma_login is set to 1 by default. This means SSO is used as default for phpMyAdmin via DirectAdmin: https://docs.directadmin.com/change...click-phpmyadmin-access-is-enabled-by-default

We however use an own hosted phpMyAdmin enviroment so we don't use SSO. Now with DirectAdmin 1.666 you get a `Failed to open phpMyAdmin` error if you press the phpMyAdmin buttons in DirectAdmin.

To try to resolve this I set `one_click_pma_login` to 0 but than all buttons to phpMyAdmin disappear in DirectAdmin.

Is there a way to keep all the phpMyAdmin buttons in DirectAdmin without making use of SSO?
The buttons in our case just have to point to https://hostname/phpmyadmin/ as with DirectAdmin 1.665 and before.

I know I can add a custom button to the menu but than still other buttons in the MySQL sections are missing to phpMyAdmin.
 
Thanks for the feedback @Joriz. I think the best way forward would be to just make sure SSO works with the custom phpMyAdmin (not managed by CB). The SSO support does not need any modification to the PMA it is all done in the config.inc.php (with one small exception of dropping a static sso_logout.php file in the PMA main dir).

If integrating SSO is not an option (for example PMA is on another server), then second best option would be to create a static menu entry with a link to PhpMyAdmin. There is no other way for DirectAdmin to be aware of PMA that is outside of DA control.

The legacy behaviour of just redirecting to PMA login screen was a leftover from the times when DA did not support SSO integration.
 
A fix for the DA installer is released to fix automatic license key detection.
 
Hmmmm... I have ~7500 databases and till DA 1.664 phpmyadmin with SSO was loading everytime within ~10 minutes, but on DA 1.665 something changed and it was not 10 minutes but 10 seconds... I was very happy... but with 1.666 it's again ~10 minutes - did you change something (like downgrade in that function)?
 
ShinJii said:
Hmmmm... I have ~7500 databases and till DA 1.664 phpmyadmin with SSO was loading everytime within ~10 minutes, but on DA 1.665 something changed and it was not 10 minutes but 10 seconds... I was very happy... but with 1.666 it's again ~10 minutes - did you change something (like downgrade in that function)?
Click to expand...
maybe it related to database size count, there was strings about this in skin translation.
 
@ShinJii, the key change that affects this, is the recently introduced compatibility with MySQL partial_revokes mode. With partial_revokes we can not use DB access grants that has wildcard matches (% symbol). The PMA SSO, has two modes:
  1. Global access (when accessed from the DB list page, or menu).
  2. Single DB access (accessible from single DB info page).
In DA 1.665 global access was granted with a single GRANT statement, for example GRANT ALL ON `user\_%`.* TO `tmp_sso_user`@localhost. In DA 1.666 to be compatible with partial_revokes mode global access gets separate GRANT statements for each DB user owns, for example:
  • GRANT ALL ON `user\_db1`.* TO `tmp_sso_user`@localhost
  • GRANT ALL ON `user\_db2`.* TO `tmp_sso_user`@localhost
  • ...
For small number of database it does not really matter much. It should not matter much if you have many databases on the server as long as a single user does not have thousands of databases. If single user does not have many databases (only big number of total DBs on server), yet you still got a performance hit, it could mean that extra steps like checking the list of databases is taking too long.

If you would give us access to the server (via the support ticket) we could check investigate it further.
 
A hot-fix update is released prevent main server cert issue failure when an additional sever certificate domains is a wildcard domain that covers main server name.

Prior to this change, for example example having servername=server.example.net and acme_server_cert_additional_domains=*.example.net, would end up with an error from LetsEncrypt stating that *.example.net already includes server.example.net. The update detects such configuration end excludes server name from the certificate request when it is not needed.
 
fln said:
@ShinJii, the key change that affects this, is the recently introduced compatibility with MySQL partial_revokes mode. With partial_revokes we can not use DB access grants that has wildcard matches (% symbol). The PMA SSO, has two modes:
  1. Global access (when accessed from the DB list page, or menu).
  2. Single DB access (accessible from single DB info page).
In DA 1.665 global access was granted with a single GRANT statement, for example GRANT ALL ON `user\_%`.* TO `tmp_sso_user`@localhost. In DA 1.666 to be compatible with partial_revokes mode global access gets separate GRANT statements for each DB user owns, for example:
  • GRANT ALL ON `user\_db1`.* TO `tmp_sso_user`@localhost
  • GRANT ALL ON `user\_db2`.* TO `tmp_sso_user`@localhost
  • ...
For small number of database it does not really matter much. It should not matter much if you have many databases on the server as long as a single user does not have thousands of databases. If single user does not have many databases (only big number of total DBs on server), yet you still got a performance hit, it could mean that extra steps like checking the list of databases is taking too long.

If you would give us access to the server (via the support ticket) we could check investigate it further.
Click to expand...
It's one user in my case with all databases :))
 
fln said:
Thanks for the feedback @Joriz. I think the best way forward would be to just make sure SSO works with the custom phpMyAdmin (not managed by CB).
Click to expand...

Thanks for the input. I was able to make a working proof of concept with our custom phpMyAdmin setup. :)
All needed files for SSO can be found in a DirectAdmin download inside custombuild/configure/phpmyadmin.
Also the folder /var/www/html/phpMyAdmin/sso/ needs to be created so temporary php-files can be stored who handle the creation of the session for phpMyAdmin.

I noticed that for every SSO attempt a new database user with a double underscore is created to handle the SSO to phpMyAdmin as described in:

Version 1.665 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

It seems those users are not removed afterwards inmediatly.

@fln Is there any process in DirectAdmin which should clean up those users? Am I missing something or do I need to be more patient?
Of course I can also create something myself to cleanup the database users.

Code: 
testuser__6s8E-c0Zt9yrjHGdl2ANcenefb8NrQVM    Full access
testuser__9lSuBiSewQkRKmRGEbJoHav_Qont3O6m    Full access
testuser__BxTR7IWlcmqfHiJgF7YuU5tp5b2fx17U    Full access
testuser__C8ioSvnjmNvTzHWiYyww-drKdkOJoPDS    Full access
testuser__GlOYEbTQYgDYPgMIsfw5SwHEiQp0EXA4    Full access
testuser___I_kqgLYzwYjVfgegcOUZBEtM-I5fmSu    Full access
testuser___YmcqLj3xkyPUT7ykOsKwIoa5lpH7j8e    Full access
testuser__jwmqxSY8k0VP1vZkyzlT7NAqtot9qeQ9    Full access
testuser__lcecRV8SiEWtvAh4FwUo5865NO4T96CR    Full access
 
@Joriz They are removed automatically after 24 hours. DA keeps track of them internally.

@ShinJii ufff that is really not the expected usage pattern. There is some room for optimizations to make SSO run faster (dynamically fallback to using access patterns if we detect partial_revokes are off at run time). However I am afraid that despite making a single operation (creating temp SSO user account) faster, there will be other places where 7.5k DBs bogs down the performance. If we could get access to your server to measure general server performance it would make it easier to see if SSO optimizations are worth pursuing.
 
One more update is released to fix a bug in LetsEncrypt renewal attempts counting logic. Ticket #58920.
 
fln said:
@Joriz They are removed automatically after 24 hours. DA keeps track of them internally.
Click to expand...
Check. That is a bit long. PhpMyAdmin sessions already expire after 1 hour so a faster cleanup to prevent too many unnecessary users seems better. Is this modifiable?

Also we noticed that the temporary MySQL users are made with `localhost` and `%` permission. As phpMyAdmin is running on localhost a `%` permission is not needed. Now the MySQL users are directly open via port 3306 to the outside.

Except those two points DirectAdmin phpMyAdmin SSO is easily intergrated when using phpMyAdmin from (another) source. (y)
 
  • Like
Reactions: fln
Some notes:

The temporary user lifetime is not configurable at the moment. It would be trivial to make it configurable via the directamdin.conf, but not quite sure if there is much value in doing it. The reason for it being this long is to minimize the possibility of user getting logged-out of PMA just because the temporary user expired. Despite being unlikely it is still possible for the user to be actively using PMA for a whole day 🤷‍♂️, or for example importing/exporting a big database.

The % is useful when DA is used with a remote database server.
 
@Joriz
Bruteforce on expired 1day token is impossible.

@fln
The % is useful when DA is used with a remote database server
Click to expand...
I thinks, this could impove by detect if it's remote host or local host, but maybe it still useless, because hacker will just coming bruteforce to phpmyadmin instead.
 
In our DA deployments we relied quite heavily upon /usr/local/directadmin/custombuild/build settings_json , this used to output the contents of the options.conf as json. Currently it outputs the help page. I did not see any reference to this in the changelog, but not sure if the command was ever officially supported.
Is there a way via the API to get this information? Will this command be back or should we change to another method for this?
 
@Aicop, yes the build settings_json was an internal command. If you need easy API like access to the CustomBuild it would be the best to use DirectAdmin API GET /api/custombuild/options-v2. It provides a flat structure for all CB settings in options.conf. Example:

Code: 
# curl -s $(da api-url)/api/custombuild/options-v2 | jq .
[
  {
    "key": "php1_release",
    "value": "8.1",
    "default": "8.3",
    "allowed": [
      "5.6",
      "7.0",
      "7.1",
      "7.2",
      "7.3",
      "7.4",
      "8.0",
      "8.1",
      "8.2",
      "8.3"
    ],
    "section": "_php_",
    "description": "Default version of PHP."
  },
  {
    "key": "php1_mode",
    "value": "fastcgi",
    "default": "php-fpm",
    "allowed": [
      "php-fpm",
      "fastcgi",
      "lsphp"
    ],
    "section": "_php_",
    "description": "Mode of the default PHP version. lsphp is only compatible with LiteSpeed, OpenLiteSpeed WWW servers or CloudLinux+Apache. For nginx (not as a reverse proxy for apache) php-fpm must be chosen."
  },
...

The internal command build settings_json was replaced by new internal command build dump_options (easier to parse with CLI tools). But I would not recommend using internal commands as they might change in the future.

Also starting DA 1.667, all options will be in single file options.conf (no long scattered between options.conf and php_extensions.conf). So reading the file directly is also an option.
 
We have just installed our first Ubuntu 24.04 server with DirectAdmin. In our templating for MySQL/MariaDB we add "performance_schema=OFF", but with Ubuntu 24.04 MariaDB seems te be compiled without support for the PERFORMANCE_SCHEMA-engine. No big issue for us, since we turn it off anyway, but without support the variable "performance_schema" is unknown causing MariaDB to crash on restart.

I have notices the same with both MariaDB 10.6 and 10.11:

Code: 
MariaDB [(none)]> show engines;
+------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+
| Engine     | Support | Comment                                                                                         | Transactions | XA   | Savepoints |
+------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+
| CSV        | YES     | Stores tables as CSV files                                                                      | NO           | NO   | NO         |
| InnoDB     | DEFAULT | Supports transactions, row-level locking, foreign keys and encryption for tables                | YES          | YES  | YES        |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables                                       | NO           | NO   | NO         |
| Aria       | YES     | Crash-safe tables with MyISAM heritage. Used for internal temporary tables and privilege tables | NO           | NO   | NO         |
| MyISAM     | YES     | Non-transactional engine with good performance and small data footprint                         | NO           | NO   | NO         |
| MRG_MyISAM | YES     | Collection of identical MyISAM tables                                                           | NO           | NO   | NO         |
| SEQUENCE   | YES     | Generated tables filled with sequential values                                                  | YES          | NO   | YES        |
+------------+---------+-------------------------------------------------------------------------------------------------+--------------+------+------------+

Strangely when installing MariaDB 10.11 from the Ubuntu-repo, support for the PERFORMANCE_SCHEMA engine is available. Is this something that has changed in the install-scripts from DirectAdmin? If this is the "new" default we need to change our template.

( I'm posting this under 1.666 since this version started the support for Ubuntu 24.04 ) .
 
You must log in or register to reply here.
Back
Top