1) I tried to send a message via the "https://www.ispconfig.org/get-support/?type=migration" link but I repeatedly got a message that it could not be sent. No scripts were blocked 2) I'm trying a dry run of the Migration Tool before buying the licence. The tool is unable to login to the remote API. However, at the start of the run, it told me: "Your server has an old X3 root certificate which expired on Sept, 30th 2021. Connection via PHP/curl and other clients to servers using Let'sEncypt and other providers using this root certificate will probably fail! " I replied "no" to "Shall I remove it" as the server is still live and I do not know what else that might affect - but would it affect the API login? I have triple-checked the URL and credentials and they are correct. Is there a guide on how to troubleshoot this? Or do you have any ideas?
Just tested it, works fine for me in Chrome and Firefox. If you use Debian or Ubuntu, try: Code: sudo apt-get update sudo apt-get install --only-upgrade ca-certificates sudo update-ca-certificates on CentOS, try: Code: sudo yum update ca-certificates # or on newer: sudo dnf update ca-certificates And make sure you created a remote API user and not a ISPConfig login.
Hi Till Thanks for the swift reply - as usual Apologies for the slow response - emergency visit to vet for our cat got in the way :/ 1) The problem sending the support message - I'm using Firefox. I'll try another browser & see what happens. 2) The system is using Debian 9, so the CA certificate didn't work (after I changed the repositories to the Linux archive, as OVH no longer host them). So I've disabled that certificate with Code: sudo dpkg-reconfigure ca-certificates Still didn't work, so I moved the crt our of the way, and now it no longer gives the warning. But the API login still fails. It did take a few tens of seconds. There's no useful information in the migration tool log. I'll go look on the target machine & see what I can find. BTW, yes, it's an API user Later: On the target system, in the ISPConfig auth.log, it just says: I copied and pasted both username and password from the Remote User page on the target to the migration tool prompts , via SSH, on the source machine, so I know they're right. I don't know if this matters: The tool asks for the IP address used for outgoing connections. It defaults to 127.0.1.1 on this system. I input the server's public IP address.
If you get a failed login error in the log, then SSL is not an issue; it's simply a wrong username or password or you might have restricted the remote user to a wrong IP address. Try not to restrict it to an IP. Set a new password, maybe it's a problem with certain characters, try using just characters a-zA-Z0-9 and test again. I'm not aware that anyone ever reported a login issue for the remote user connection, except for some users mixing up ISPConfig and remote users in the past. So the issue you have is really uncommon. In any case, it's more likely an issue with your new system than an issue with the tool.
Thanks Till. I did originally set restricted IP addresses but removed them when I started dealing with this problem. I created a new Remote user and used the built-in password generator (although that had a # in it). I also tried a PW without a #. No address restrictions. Given you've not seen this before, I'm inclined to agree with that Although I can't imagine what's causing it. I've disabled fail2ban, and normal ISPConfig login works OK, as does SSH. There's no firewall ATM, because I haven't yet configured/activated CSF, my preferred firewall/login monitor. I'll probably eventually find something daft that I've done :/ Just a thought: It's a brand new ISPConfig3 installation, done with the automated installer. No users, domains nor anything else have been created. I'd assume that's a fairly common thing, so I don't expect it's relevant... but I've been caught by things like that before. I could probably find this in the documentation but... does the target have to be set into Migrate mode? Anyway, I'll have a dig around over the next day or so & see what I can find.
I found that the ISPConfig time zone on the target server was not the same as the System time zone - I think I changed the system one after installing ISPConfig, but didn't realise that it had to be manually changed on the latte. Anyway, fixed now. Unfortunately, it didn't cure the problem (not that I could see why it should but one can hope ) So I thought I'd add some detailed debug calls in the remote login code on the target. I was looking at interface/lib/classes/remoting.inc.php but I think I'm in the wrong place, because it requires a user that belongs to a client. Any chance you please point me to the right area (just a folder/file)?
That's the right file, and it does not require a client. Though its supports a client login, but that's not used by default and not used here. The remote user is queried in line 157 and then the password is checked.
Thanks again! Found the right part Seems I'm a little out of practice (retired 12 years ago). I'll try not to bother you again until I've found a solution.
The fact that none of the log requests that I had put in that file were triggered were a bit of a clue I was right - it was something stupid on my part, and I should have realised it much earlier :/ The firewall that I use - Config and Firewall Server (CSF) is brilliant. But I had forgotten that it limits what outbound ports are open - and 8080 wasn't one of them. Yes, I felt a right twit! Open port 8080 and... bingo! A successful dry run!! A couple of things I'm not too clear about, though: * If a (target) server is using both IPv4 and v6 addresses, I assume it doesn't matter which one you give as the "primary address". * the target server address is requested more than once during the run, once during establishing connection with the target server and again shortly after the actual run begins. I assume it should be the same address each time. Thanks again for your patience, Till
Better use the IPv4 address. If you have a single server setup, then these are the same; on multiserver setups, they can differ. Also, there are different programs asking for an address.
