I'm upgrading one of my servers to a new Linode with more RAM as my existing Linode was running out of memory. Source is a Linode running Debian 10.10 and target is a Ubuntu running 20.04.2 LTS. Last time, I did the migration manually, but as I now have a few more sites, I went down the migration toolkit route. It looked great, however I have a few issues. The migration didn't complete fully. At the end of the migration, I ended up with the foillowing: Code: [ERROR] API call to server_config_set failed. See log file for details. [WARN] Failed setting apache config check active on the target web server. [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. Looking at the log file, I have this: Code: tail migrate.log 2021-07-26 14:19:24 - [WARN] Curl exception: cURL error: [7] Failed to connect to 192.168.151.49 port 8080: Connection refused 2021-07-26 14:19:24 - [ERROR] JSON API ERROR in API call (system_config_set): NO ACCESS 2021-07-26 14:19:24 - [ERROR] API call to system_config_set failed. 2021-07-26 14:19:24 - [ERROR] JSON API ERROR. Arguments sent were: array ( 'section' => 'sites', 'key' => 'dbname_prefix', 'value' => 'c[CLIENTID]', 'session_id' => '9108101161835f69e974f3ca3d9ef62e', ) 2021-07-26 14:19:24 - [WARN] Failed restoring prefixes on target. You find them under system -> Main config -> Sites. And I quickly realise Apache isn't running. Looking at the Apache logs, several things aren't quite right. There's the SSL issue (which I expected as the new server is to replace the old server so the certificate doesn't currently currently resolve to the new server). But there's also an issue with a mismatch in python versions and also the vhost files created on the new server have the FcgidMaxRequestLen variable but with no value set! I've compared the vhost files to those on the source server and they are the same apart from the client/site paths and this mysteriously added FcgidMaxRequestLen: Code: systemctl status apache2.service ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2021-07-26 15:45:50 UTC; 1min 20s ago Docs: https://httpd.apache.org/docs/2.4/ Process: 462304 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE) Jul 26 15:45:50 mail1 systemd[1]: Starting The Apache HTTP Server... Jul 26 15:45:50 mail1 apachectl[462320]: AH00548: NameVirtualHost has no effect and will be removed in the next release /etc/apache2/sites-enabled/000-ispconfig.vhost:7 Jul 26 15:45:50 mail1 apachectl[462320]: AH00526: Syntax error on line 246 of /etc/apache2/sites-enabled/100-xxx.com.vhost: Jul 26 15:45:50 mail1 apachectl[462320]: FcgidMaxRequestLen takes one argument, Max HTTP request length in byte Jul 26 15:45:50 mail1 apachectl[462304]: Action 'start' failed. Jul 26 15:45:50 mail1 apachectl[462304]: The Apache error log may have more information. Jul 26 15:45:50 mail1 systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE Jul 26 15:45:50 mail1 systemd[1]: apache2.service: Failed with result 'exit-code'. Jul 26 15:45:50 mail1 systemd[1]: Failed to start The Apache HTTP Server. The line 246 is the one where the FcgidMaxRequestLen is inserted with no value. There was a similar issue earlier in the file for the http version which I commented out, pushing the first error to line 246 which is the https version. I'd like to avoid having to manually remove the FcgidMaxRequestLen variable from all the vhost files as there are quite a few. Thoughts on where to go from here? Thanks.
The value of FcgidMaxRequestLen is set fixed in the host config template that ships with ISPConfig, line 320 in the vhost.conf.master is: FcgidMaxRequestLen 1073741824 I don't see any possibility of how this can be empty unless you modified the template or are using a custom template. Check your template and then you can use Tools > Resync in ISPConfig to let ISPConfig write the config files again. Regarding SSL problems, there are normally no SSL issues as ISPConfig does not recreate the SSL certs during migration, it just copies them over. This works, unless you have chosen to skip moving SSL certs or if you have chosen to use a different LE client, a migration requires it to have the same LE client on old and new system (see prerequisites section in the migration tutorial).
Thanks Till. There was a warning when I started regarding templates: Code: ... WARNING! client templates can not be imported! All imported clients will have their correct limits but no template assigned! ... Ahh, I think I know what the problem is. For some reason, one client has been deleted, but the websites associated with him are still in operation, including the site throwing up the error. I will recreate the client, update the site so it corresponds to the new client and try the import again.
I meant config file templates in /usr/local/ispconfig/server/conf and /usr/local/ispconfig/server/conf-custom/, not the client templates.
All of my websites now have migrated and appear to work OK. But I now have discovered two new issues: 1. Email isn't being delivered. Roundcube has been installed and is working, my Thunderbird also works and reflects what's on the server. But if I email a mailbox on the server, it just doesn't appear. Emails don't bounce, they're just not deliivered. Email sent from the server isn't received, but is saved in the sent folder. I've looked at MXtoolbox.com and everything appears to be OK. I have DKIM, SPF, etc set up. I "swapped" IP addresses from the old server to the new one so as far as the external world is concerned, everything is as it was before. I think the problem is therefore with a setting on the server. I followed the perfect server guide and didn't notice any errors. ISPconfig is showing green as far as email is concerned... I'm looking at a few logs and nothing looks out of place. Initially, the email server had connection refused on 127.0.0.1 and I realised the firewall rules hadn't been created so I clicked on Add Firewall record in the system -> Firewall and it auto-populated. I've saved that and rebooted, but still have the problem.
Found the problem - Amavis wasn't starting because the hostname reported was just the hostname and not the FQDN. I traced this down to not having my server's FQDN in the /etc/hosts file. All fixed now Until the next issue!