How to migrate a website area from a server to another

One problem I found (sent to me via email, not in the logs), indeed, is that for some odd reason this user didn't have SELECT rights on the sys_group table in the master db, but it was fine for everything else. No idea how that happened, I just ran the regular installer and didn't get any warning out of it.

Besides the above, no relevant problems are logged from what I can see, and also clicking a resync of "client and reseller" didn't help.

for reference, here is the debug output of a later resync of the web part:

Code:

Thu Oct 28 18:20:01 CEST 2021 28.10.2021-18:20 - DEBUG - Calling function 'check_phpini_changes' from plugin 'webserver_plugin' raised by action 'server_plugins_loaded'.
Thu Oct 28 18:20:01 CEST 2021 28.10.2021-18:20 - DEBUG - Found 1 changes, starting update process.
Thu Oct 28 18:20:01 CEST 2021 28.10.2021-18:20 - DEBUG - Replicated from master: REPLACE INTO `web_domain` (`domain_id`,`sys_userid`,`sys_groupid`,`sys_perm_user`,`sys_perm_group`,`sys_perm_other`,`server_id`,`ip_address`,`ipv6_address`,`domain`,`type`,`parent_domain_id`,`vhost_type`,`document_root`,`web_folder`,`system_user`,`system_group`,`hd_quota`,`traffic_quota`,`cgi`,`ssi`,`suexec`,`errordocs`,`is_subdomainwww`,`subdomain`,`php`,`ruby`,`python`,`perl`,`redirect_type`,`redirect_path`,`seo_redirect`,`rewrite_to_https`,`ssl`,`ssl_letsencrypt`,`ssl_letsencrypt_exclude`,`ssl_state`,`ssl_locality`,`ssl_organisation`,`ssl_organisation_unit`,`ssl_country`,`ssl_domain`,`ssl_request`,`ssl_cert`,`ssl_bundle`,`ssl_key`,`ssl_action`,`stats_password`,`stats_type`,`allow_override`,`apache_directives`,`nginx_directives`,`php_fpm_use_socket`,`pm`,`pm_max_children`,`pm_start_servers`,`pm_min_spare_servers`,`pm_max_spare_servers`,`pm_process_idle_timeout`,`pm_max_requests`,`php_open_basedir`,`custom_php_ini`,`backup_interval`,`backup_copies`,`backup_excludes`,`active`,`traffic_quota_lock`,`fastcgi_php_version`,`proxy_directives`,`enable_spdy`,`last_quota_notification`,`rewrite_rules`,`added_date`,`added_by`,`directive_snippets_id`,`enable_pagespeed`,`http_port`,`https_port`,`log_retention`,`folder_directive_snippets`) VALUES ('2544','1','1321','riud','ru','','16','*','','XXXXX','vhost','0','name','/var/www/clients/client1320/web2544','','web2544','client1320','-1','-1','n','n','y','1','1','none','fast-cgi','n','n','n',NULL,NULL,NULL,'n','n','n','n',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,'awstats','All','','','y','dynamic','10','2','1','5','10','0','/var/www/clients/client1320/web2544/web:/var/www/clients/client1320/web2544/private:/var/www/clients/client1320/web2544/tmp:/var/www/XXXXXXX/web:/srv/www/XXXXXX/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin','','none','1',NULL,'y','n','PHP 7.2:/usr/bin/php-cgi7.2:/etc/php/7.2/cgi','','n',NULL,NULL,'2021-10-28','admin','0','n','80','443','10',NULL)
Thu Oct 28 18:20:01 CEST 2021 /usr/bin/fail2ban-client
Thu Oct 28 18:20:01 CEST 2021 /sbin/iptables
Thu Oct 28 18:20:01 CEST 2021 /sbin/ip6tables
Thu Oct 28 18:20:01 CEST 2021 PHP Warning:  Use of undefined constant openvz_tools - assumed 'openvz_tools' (this will throw an Error in a future version of PHP) in /usr/local/ispconfig/server/lib/classes/cron.d/100-monitor_openvz.inc.php on line 72
Thu Oct 28 18:20:01 CEST 2021 PHP Warning:  Use of undefined constant openvz_tools - assumed 'openvz_tools' (this will throw an Error in a future version of PHP) in /usr/local/ispconfig/server/lib/classes/cron.d/100-monitor_openvz.inc.php on line 101
Thu Oct 28 18:20:01 CEST 2021 28.10.2021-18:20 - DEBUG - Calling function 'ssl' from plugin 'apache2_plugin' raised by event 'web_domain_update'.
Thu Oct 28 18:20:02 CEST 2021 28.10.2021-18:20 - DEBUG - Calling function 'update' from plugin 'apache2_plugin' raised by event 'web_domain_update'.
Thu Oct 28 18:20:02 CEST 2021 28.10.2021-18:20 - DEBUG - Creating symlink: ln -s /var/www/clients/client1320/web2544/ /var/www/clients/client1320/XXXXXX
Thu Oct 28 18:20:03 CEST 2021 28.10.2021-18:20 - DEBUG - Creating fastcgi starter script: /var/www/php-fcgi-scripts/web2544/.php-fcgi-starter
Thu Oct 28 18:20:03 CEST 2021 28.10.2021-18:20 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/XXXXXX.vhost
Thu Oct 28 18:20:03 CEST 2021 28.10.2021-18:20 - DEBUG - Apache status is: running
Thu Oct 28 18:20:04 CEST 2021 28.10.2021-18:20 - DEBUG - Calling function 'restartHttpd' from module 'web_module'.
Thu Oct 28 18:20:04 CEST 2021 28.10.2021-18:20 - DEBUG - Restarting httpd: systemctl restart apache2.service
Thu Oct 28 18:20:04 CEST 2021 28.10.2021-18:20 - DEBUG - Apache restart return value is: 0
Thu Oct 28 18:20:07 CEST 2021 28.10.2021-18:20 - DEBUG - Apache online status after restart is: running
Thu Oct 28 18:20:07 CEST 2021 28.10.2021-18:20 - DEBUG - Processed datalog_id 199006
Thu Oct 28 18:20:07 CEST 2021 28.10.2021-18:20 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
Thu Oct 28 18:20:08 CEST 2021 finished.

Something I should have said LONG ago (apologies for that!): I'm running with ispconfig 3.1.13p1, as we have some ubuntu 14.04 servers we still need to maintain for a little while more, and that's the latest ispconfig version supporting it; that also means that the above log comes from ubuntu 18.04 (which is the latest ubuntu version supported by that ispconfig) for now. (I really want to finish this part, so I can then move on to actually looking at upgrading those old servers…)

 

i don't think there's any reason to worry about the non-existence of the /var/www/clients/client0 folder, i believe that will only be created if there is actually a website created and owned directly by admin.
the debug logs show that it's creating the symlinks for a site.

so the only problem should be the file/folder permissions. i'm not sure if/how not having select on sys_group would affect that. i can see that at least on 3.2.* that the ispcsrv* users have select on `dbispconfig`.`sys_group`, don't have an older version to check, but i suspect they'd be the same. it can be changed manually, but i don't know if not having that correct now means some other updates may not have fully applied any db changes.

 

It might also have been related to the sys_group table thing: once I fixed that it looks like ispconfig didn't feel the need to have that client0 folder/user.

(sorry, amongst many tries and test it's hard on me to remember all the details I come across )

I indeed added the grant manually on the master db; the error went away, but a resync still didn't set the correct ownership to the files.

Incidentally, creating a new website on that host does give it the correct ownership (and the ispconfig debug log does have "DEBUG - exec: chown -R web2545:client1320 /var/www/clients/client1320/web2545/web", etc), so I might just reckon that resync doesn't chown everything.