migration tool error on couple of domains that were NOT on target server!

got a couple of (admittedly minor) errors during migration:
2021-09-13 23:24:53 - [ERROR] API call to dns_a_add failed.
2021-09-13 23:24:53 - [ERROR] JSON API REPLY ERROR: ip_error_wrong<br />^M
- Arguments sent were: array (
'client_id' => 0,
'params' =>
array (
'_ID_' => '870',
'server_id' => '1',
'zone' => '122',
'name' => 'widsith.com.',
'type' => 'A',
'data' => '8332 richmond highway',
'ttl' => '3600',
'stamp' => '2021-09-13 23:24:53',
'serial' => '2021091301',
'active' => 'Y',
'sys_perm_user' => 'riud',
'sys_perm_group' => 'riud',
'sys_perm_other' => '',
'aux' => '0',
'_migrate_status' => NULL,
'_migrate_status_type' => NULL,
'_migrate_status_dep' => NULL,
'_primary_id' => '870',
),
'session_id' => '62348bbe9f46cb584321db8b8812b67d',
)
2021-09-13 23:24:54 - [ERROR] API call to dns_a_add failed.
2021-09-13 23:24:54 - [ERROR] JSON API REPLY ERROR: ip_error_wrong<br />^M
- Arguments sent were: array (
'client_id' => 0,
'params' =>
array (
'_ID_' => '871',
'server_id' => '1',
'zone' => '122',
'name' => 'www',
'type' => 'A',
'data' => '8332 richmond highway',
'ttl' => '3600',
'stamp' => '2021-09-13 23:24:54',
'serial' => '2021091302',
'active' => 'Y',
'sys_perm_user' => 'riud',
'sys_perm_group' => 'riud',
'sys_perm_other' => '',
'aux' => '0',
'_migrate_status' => NULL,
'_migrate_status_type' => NULL,
'_migrate_status_dep' => NULL,
'_primary_id' => '871',
),
'session_id' => '62348bbe9f46cb584321db8b8812b67d',
)

what does the ip_error_wrong signify?

 

also another question somewhat related - if I have 2 servers ns10 and ns9 is there an easy way to take the two and make one the slave ispconfig instance? without messing anything up? or am I dreaming?
cdb.

 

and maybe (i don't know if the mig-tool handles this right now) copy the dnssec-files from the old to new server (/etc/bind/) before starting the migration. othewise all zones will get new keys.

 

thanks till that was all it was I had a screwed up DNS zone. now why ispconfig would LET me store my shop street address as an ip is a different question
and hmm does the tool break dnssec? that is a good question.

 

answer yes the DNSSEC entries are different after migration!

 

copy the *key and *private from the source to the master BEFORE you start the mig-tool. it's a pain if you have to update all dnssec-keys at your registrar.

 

hmm some other issues with the migration. fixed the dns error but I'm getting not expected behaviour.
on the screen:
2388/3336 Syncing /var/vmail/ ...etc.
[2389/3336] Syncing /var/lib/mailman...
then [WARN] Source dir/file /var/lib/mailman/messages/ for mail server does not exist
[2392/3336] Syncing /var/lib/mailman/spam
[3336/3336]
Migration tool run completed.

ie nothing between 2392 and 3336! but looking at migrate.log last few lines have
[INFO] Successfully executed command rm -rf '/tmp/dumps'
[WARN] JSON API ERROR: session expired. Trying re-login!
(end of file).
hmmm

 

looking in main config where is it?

 

I have just noticed that SSL certs are apparently NOT created. and unchecking and rechecking the SSL and LetsEncrypt boxes do NOT put anything in the ../ssl folder or in the *vhost files! how do i find out why the SSL certs are not being created?? or the vhost not being modified?

 

I noticed that on the source server there were no ssl files for a certain domain website and I checked the boxes ssl and lets encrypt, saved - but no ssl files were generated.

 

I see that after I check the ssl and letsencrypt boxes and save, it thinks for a few minutes but when I return to the domain the boxes are still unchecked!

 

more weirdness locking at /var/log/letsencrypt/letsencrypt.log I see:
--snip--
021-09-21 19:31:04,702EBUG:certbot._internal.plugins.selection:Selected authenticator <certbot._internal.plugins.webroot.Authenticator object at 0x7f182ff19438> and installer None
2021-09-21 19:31:04,702:INFO:certbot._internal.plugins.selectionlugins selected: Authenticator webroot, Installer None
2021-09-21 19:31:04,713EBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/certbot", line 11, in <module>
sys.exit(main())
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/main.py", line 15, in main
return internal_main.main(cli_args)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/_internal/main.py", line 1358, in main
return config.func(config, plugins)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/_internal/main.py", line 1225, in certonly
le_client = _init_le_client(config, auth, installer)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/_internal/main.py", line 603, in _init_le_client
acc, acme = _determine_account(config)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/_internal/main.py", line 511, in _determine_account
acc = display_ops.choose_account(accounts)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/display/ops.py", line 84, in choose_account
"Please choose an account", labels, force_interactive=True)
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/display/util.py", line 499, in menu
self._interaction_fail(message, cli_flag, "Choices: " + repr(choices))
File "/opt/eff.org/certbot/venv/lib64/python3.6/site-packages/certbot/display/util.py", line 462, in _interaction_fail
raise errors.MissingCommandlineFlag(msg)
certbot.errors.MissingCommandlineFlag: Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['ns10.cdbsystems.com@2020-10-01T12:44:16Z (cc8c)', 'ns9.cdbsystems.com@2018-03-09T14:07:50Z (6476)']
2021-09-21 19:31:04,714:ERROR:certbot._internal.log:Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['ns10.cdbsystems.com@2020-10-01T12:44:16Z (cc8c)', 'ns9.cdbsystems.com@2018-03-09T14:07:50Z (6476)']
--snip--

 

so where is it getting ns9 from? this is something just from today its long after migration was done last week... but on the source server (ns10). where does it find ns9??

 

enlightenment -
/etc/letsencrypt/accounts had 2 entries one from 2018 and json refs ns9.
the one from 2019 has json reffing ns10.
but why would one not get deleted?

 

.... but now I have another issue there are also 2 accounts on the target server after migration -
I moved the 2018 account to under root to fix the source server. (having only 1 letsencrypt account).
but on the target server, the one referring to ns10 (source) moving it did NOT help. still cant save the letsencrypt settings and create the ssl files on the target.
and the 2019 line on the target server has a ln reference to the 2018 line! so they are entangled it seems....
sad.