DirectAdmin v1.659

One of the old servers installed this update.

However, user databases cannot be created.
All user accounts have the same problem.

error code
Failed to create database
Internal Error

How can I solve this?
 
Yes it works
mysqld 10.4.21

The old .sql files on the server are active and working, meaning the websites are online, but I cannot create new ones. A new database cannot be created in both old accounts and newly created accounts.
 
@drc, for any internal server error there should be an explanation or reason for it in the server logs. You can check it with journalctl -u directadmin.

We have received some reports for having the following error:

Code: 
Feb 06 10:00:00 server.example.com directadmin[1234]: creating database with user error=Error 1615 (HY000): Prepared statement needs to be re-prepared hostPatterns=[localhost] name=user_dbname req-uri=/api/db-manage/create-db-quick req-user=admin|user
...

This happens if server has too low value set in the table_definition_cache. This usually means that not only DA but normal websites using prepared statements might start failing. If you increase the table_definition_cache value it starts working fine, both for DA and for user websites.

This is because new DB management page uses prepared statements. So this only reveals already existing problem on the server.
 
  • Like
Reactions: drc
I saw similar error on journalctl.

Feb 14 20:36:59 xx.xx.com directadmin[12466]: creating database with user error=Error 1615 (HY000): Prepared statement needs to be re-prepared hostPatterns=[localh...

There is no table_definition_cache value in /etc/my.cnf.
Does adding it to my.cnf and restarting the mysql server fix it?

Is 50,000 a good value?
Reference https://forum.directadmin.com/threads/are-these-settings-good-enough-for-mariadb.66518/
 
@drc
table_definition_cache

about this value.
if you have too much site running in your server, you need to adjust this value from time to time and must calculate with match your hardware . Because default value doesn't enought.

Adjust 3 value.
Code: 
table_open_cache = total_tables*Threads_connected*.50
open_files_limit= table_open_cache*2
table_definition_cache = table_open_cache

this how I tuning my server.
other relate value, please google find by yourself.
 
I've identified another issue with the deletion of hosts on the new database page. Currently, there is a limit of 30 hosts to be registered. One of our clients has 40 hosts registered, and whenever I try to delete any IP or hostname from the host list, I receive the error:

Invalid Request
User should have at least one host and no more than 30

As a result, we are unable to delete anything. How should we proceed with the deletion of IPs (or hostnames) in cases where the client already has more than 30 hosts registered?

Thanks! ?
 
exlhost said:
Did you try this before updating?

Most straightforward way to clean-up old system would be:
  1. da build remove_items - remove all libraries except iconv.
  2. da build remove_old_local libiconv - remove iconv.
  3. da build all - rebuild everything. Note: after iconv is removed, but before everything is rebuilt some services will not work if restarted.

A more cautions approach minimizing service downtime could be:
  1. da build list_removals - check how many of the old libraries there are, useful if any of them needs to be restored.
  2. da build remove_items - remove all libraries except iconv.
  3. da build remove_old_local libiconv - remove iconv and create backup (actually only to create backup :)).
  4. da build restore_old_local libiconv - restore back iconv so that all existing software would work fine for the time being.
  5. rm -f /usr/local/include/{iconv.h,libcharset.h,localcharset.h} - remove only iconv headers (we still have full iconv backup just in case)
  6. da build all - rebuild everything, iconv from /usr/local should not be used by the rebuit software
  7. da build remove_old_local libiconv - remove iconv for good now.
Click to expand...
Hi THANK YOU A LOT FOR GETTING BACK AT ME,
I followed along this toppic:

Updating PHP 8.1 error

By update cd /usr/local/directadmin/custombuild ./build update ./build clean ./build versions da build update_versions Get error on iconv checking if iconv is glibc's... yes checking if iconv supports errno... no configure: error: iconv does not support errno doPhp_build: failed to compile...
forum.directadmin.com forum.directadmin.com

Aviced by ericosman, I've followed the previous toppic and :

cd /usr/local/directadmin/custombuild
./build update
./build list_removals
./build remove_items
./build remove_old_local libiconv
./build build all
Click to expand...

Did exactly that at own risk, and it solved the issue took forever to delete and update but it was due to an old library I asume. After that I could update as before without any issues.
 
@paulonichio, we are working on improving situation with too many access hosts, in the next version we will add a button to allow swapping all the hosts with a % wildcard pattern. Then without loosing existing access users can continue to manage access hosts by adding only the needed hosts, and removing wildcard pattern if it is not needed anymore.
 
One more update is released, it improves the link to PHPMyAdmin in the DB management page to be not visible if PMA is not available.
 
I don't know if it's new this release but the Last password change info box on Email Accounts page is not visible enough. Too much transparency and the text behind the info box is too visible (the email address). Perhaps not clearly visible on the screenshot due to the removal of the email address, but the date in the info box is not very visible at first glance. In Safari.

Schermafbeelding 2024-02-15 om 10.58.36.png

Same with other info boxes I see now. Less transparency is better I think.
 
Export Database issue, then i press Export DB i receive the follow error:
ERR_HTTP2_PROTOCOL_ERROR

any idea?
 
Is the ./build php n command not working anymore?
It says:
invalid or not enabled PHP version 'n'
Click to expand...

Also I tried to remove 2 php versions somewhere which aren't used anymore. Removed the php versions from options.conf.
But ./build list_removals does not show anything to remove.

Any idea?

I could remove them manually, but normally the removals command should do this.
 
Can we have the old database GUI back? The new one is more complicated. And any option which allows end user to choose username, which is different than db name, for a new database? Right now, whenever creating a new db, an user with the same name as db name is created automatically!
 
@gate2vn, old UI were creating an user account with database automatically as well. This user account (that matches DB name) is expected to be used when accessing the DB. Using main DA account and credentials was not a good practice which we are trying to discourage.

The important thing that actually changed with this release is that new databases are not automatically available for the DB user account which has the same name as DA user account. This change is to make sure users would not try and use their main account (and main password) when connecting to the databases from application.

Please make sure you have PhpMyAdmin SSO enabled (you can enable it with commands da config-set one_click_pma_login 1 --restart + da build phpmyadmin). When PMA SSO is enabled you can easily access any database without knowing the DB specific password and use DB specific accounts only when setting up new web applications.
 
You must log in or register to reply here.
Back
Top