recovering from disaster....

I use --use-certbot for that reason in the new build. how do I delete the account? on ns10 (source) both the v01 and v02 api account folders point to the same place (v01)!
do I just delete the v02 api folder and redo the migration (after wipe and reload deb12/ispconfig)?
do I change ns9 to ns10 in the meta file since it no longer exists?

one more thing, can I do a migration completely within my local network to a server that may not have a 'public' ip yet? so both would be 192.168.2.xxx ?

 

I thought I had asked - but when I do a migration, can I migrate to a server that is on a LOCAL ip, but has no public ip yet?
ie from 192.168.2.x to 192.168.2.y where the source DOES have a public ip (ns10). the target will have a public ip in future, but currently it may just have the local ip.
does that work? or must both be reachable from the big bad world?

also - I'm getting back the /var tree from the dead server. nothing I can boot of course.
but when I have /var/www I can copy the domains and their websites to same corresponding folder on new server.
when I have /var/lib/mysql I can copy over the databases for these domains to the same database name on new server (which may not exist until I make the copy.
and /var/mail/vmail will get the emails associated with these domains.
from what I can see, copying over the database and the /web folder seems to be enough to bring up the website once database is correct.
mysql should see the database properly when the database mynewdb (from/var/lib/mysql/mynewdb) off the recovered drive is added to /var/lib/mysql/mynewdb folder on new drive. so I need to do anything to register it with mysql? or is the presence of the folder enough (with correct permissions of course).
same with the emails right? if I copy over the /var/vmails/whoever folder from recovered drive to /var/vmail, and delete the cache, dovecot will recreate it including all the new emails next login wont it?
maybe nightmare is almost over...
thanks for your continued and invaluable help till. now about mailman.... (grin)

 

ok - so how about I use a brand new server running deb12, NOT with autoinstaller, then install mysql and copy the entire /var/lib/mysql folder from the failed server. you think mysqldump would then work correctly?
the failed server was running deb12.

 

If it's just another Deb12 vm, just go for it. You've got nothing to loose to copy to it right?

 

trying the migration to a local ip, it fails at the 'give URL to login to the /remote/' matters not if I give https or http, API calls fail.
the local ip address has no SSL yet, obviously.
I seem to remember there was a way to migrate without the SSL login?

 

ok I tried to find the old post but could not.
during migrate at the URL connect (which is to https://192.168.2.xx:8080/remote/) I get the API connection failure.
doing a wget on the address gives:
wget https://192.168.2.230:8080/remote/
--2025-11-08 07:01:06-- https://192.168.2.230:8080/remote/
Connecting to 192.168.2.230:8080... connected.
ERROR: The certificate of ‘192.168.2.230’ is not trusted.
ERROR: The certificate of ‘192.168.2.230’ hasn't got a known issuer.
The certificate's owner does not match hostname ‘192.168.2.230’

which of course it does not match. I thought we could migrate to a local ip that has no public ip yet? how is this achieved?
http://192.168.2.230:8080/remote/ also gives same error. what am I missing?
could not find the old post about how to disable SSL (I think it was a centos to debian migration?)

 

another issue - I just redid the migration from ns10 to ns11 (not the internal ip one above different server)
and migrate completes but I see:

[2687/4239] Syncing /var/lib/mailman/spam/ to /var/lib/mailman/spam/
0 100% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/1)
[4239/4239]
[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.

tailing migrate.log produces:
[root@ns10 migration]# tail migrate.log
2025-11-08 16:42:26 - [WARN] Curl exception: cURL error: [7] Failed to connect to ns11.cdbsystems.com port 8080: Connection refused
2025-11-08 16:42:26 - [ERROR] JSON API ERROR in API call (system_config_set): NO ACCESS
2025-11-08 16:42:26 - [ERROR] API call to system_config_set failed.
2025-11-08 16:42:26 - [ERROR] JSON API ERROR. Arguments sent were: array (
'section' => 'sites',
'key' => 'dbname_prefix',
'value' => 'c[CLIENTID]',
'session_id' => 'q3cf763fc624750ab1ef480a6e58a68ac23e61d53',
)
2025-11-08 16:42:26 - [WARN] Failed restoring prefixes on target. You find them under system -> Main config -> Sites.

hmmm. loss of communication for some reason???