Odd issue - migtool does not complete, and ssh window closes!

That is obviously the source of the problem. But surely migration should tell the user what the mysql password on the target server is (as the default,) then I could have said "that's not right" and entered the new password. And I don't recall anywhere in ispconfig docs the warning "if you change the mysql password you must update the value stored in mysql_clientdb.conf"?? Did I miss it?
Finally as I had not seen any odd results what is the effect of having wrong root password stored there? I'll have to check several servers. And if this is so important should not ispconfig let you change the mysql PW within ispconfig itself to keep the values in sync?

 

I honestly dont remember why I changed it probably some package required root password and I thought I had simply forgotten it!
a suggestion though- in the old days before autoinstaller we picked our own mysql passwords. and then it would not have been an issue.
can autoinstaller prompt us for a mysql root password (with maybe the secure autogenerated one as a default if nothing picked).
and as long as ispconfig has the root mysql password, it should be able to change it within the control panel? might be convenient if you really HAD to change it!
wont matter here as I'm wiping the server installing deb13 and I'll be sure NOT TO TOUCH MYSQL PASSWORD!!!

sorry for being silly. but might be a thought to let us select the password as we used to do during autointall!
I always change the admin password anyway after install. a feature to change root mysql password would not be a bad thing.
on another subject dont you LOVE it that cPanel has that HUGE GAPING security hole? I'd email all cpanel sites and say 'come check out ispConfig!;!

 

mystic is indeed impressive if the news is to be believed. finding unknown security issues in EVERYTHING. but the cpanel flaw is ginormous. It makes me happy to be using ISPConfig!

 

after debian13 complete wipe and auto-config install taking care to change NO passwords, the migration seems to have worked, but have some unusual information at the end of the process:

[351/351]
[ERROR] API call to server_config_set failed. See log file for details.
[WARN] Failed setting migration mode inactive on the target web server.
[ERROR] API call to system_config_set failed. See log file for details.
[WARN] Failed restoring prefixes on target. You find them under system -> Main config -> Sites.


=============
Migration tool run completed.
You have new mail in /var/spool/mail/root
[root@ns1 migration]#

hmm! from migrate log:

Code:

2026-05-19 08:39:15 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns2.knight-kingdelivery.com
 port 8080: Connection refused
2026-05-19 08:39:15 - [ERROR] JSON API ERROR in API call (server_config_set): NO ACCESS
2026-05-19 08:39:15 - [INFO] Trying again (server_config_set)
2026-05-19 08:39:17 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns2.knight-kingdelivery.com
 port 8080: Connection refused
2026-05-19 08:39:17 - [ERROR] JSON API ERROR in API call (server_config_set): NO ACCESS
2026-05-19 08:39:17 - [ERROR] API call to server_config_set failed.
2026-05-19 08:39:17 - [ERROR] JSON API ERROR. Arguments sent were: array (
  'server_id' => '1',
  'section' => 'server',
  'key' => 'migration_mode',
  'value' => 'n',
  'session_id' => 's5747c8922ca6c73c75562d82f43ce357c8a6e9df',
)
2026-05-19 08:39:17 - [WARN] Failed setting migration mode inactive on the target web server.
2026-05-19 08:39:17 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns2.knight-kingdelivery.com
 port 8080: Connection refused
2026-05-19 08:39:17 - [ERROR] JSON API ERROR in API call (system_config_set): NO ACCESS
2026-05-19 08:39:17 - [INFO] Trying again (system_config_set)
2026-05-19 08:39:19 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns2.knight-kingdelivery.com
 port 8080: Connection refused
2026-05-19 08:39:19 - [ERROR] JSON API ERROR in API call (system_config_set): NO ACCESS
2026-05-19 08:39:19 - [INFO] Trying again (system_config_set)
2026-05-19 08:39:21 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns2.knight-kingdelivery.com
 port 8080: Connection refused
2026-05-19 08:39:21 - [ERROR] JSON API ERROR in API call (system_config_set): NO ACCESS
2026-05-19 08:39:21 - [ERROR] API call to system_config_set failed.
2026-05-19 08:39:21 - [ERROR] JSON API ERROR. Arguments sent were: array (
  'section' => 'sites',
  'key' => 'dbname_prefix',
  'value' => 'c[CLIENTID]',
  'session_id' => 's5747c8922ca6c73c75562d82f43ce357c8a6e9df',
)
2026-05-19 08:39:21 - [WARN] Failed restoring prefixes on target. You find them under system -> Main config -> Sites.

target server seems working properly, so why would it start refusing the 8080 connection?
how can I determine if the migration was infact successful? what to look for?

FURTHER INFORMATION - I started the migration over to the shiny new deb13 server and it FAILS trying to connect to xxx:8080/remote
it worked yesterday and when I look at the server with systemctl, there is NO apache2 service, and nginx.service is in red! now I did not pick nginx suring netinstall, but somehow it got selected??
and when I systemctl nginx.service i see:
1101#1101: invalid parameter "R=301,L" in /etc/nginx/sites-enabled/100-knight-kingdelivery.com.vhos

now this all worked yesterday up to the point above. all I did was add remotey (my remote customer). the migration must have created the sites under nginx and then put something that killed them???
half way through the migration nginx shut down?

the vhost contains:
rewrite ^(?!/(\.well-known/acme-challenge))/(.*)$ http://1st-street.com$2 R=301,L; index index.html index.htm index.php index.cgi index.pl index.xhtml standard_index.html;
so...where did this come from? o Till, I SWEAR I didnt not insert it just to annoy you??
happened DURING the migration, no?
obviously I should again wipe. but did auto-installer change default to nginx for deb13????


inquiring minds!