-
Notifications
You must be signed in to change notification settings - Fork 6
Log Locations
Pullsync saves logs with color control characters, so when checking a log, I recommend using less -r $logname to parse the colors correctly. The error logs display log levels:
FATAL - script dies (missing functions, control-c, etc)
ERROR - requires tech intervention but script can continue (acct fails to restore, missing dbs, ip swap problems, etc)
WARN - causes oddities but not particularly problematic to migration (app fails to install, failed to change a variable, etc)
INFO - probably safe to ignore (extra running things on source, 'good idea to look at' items that aren't really errors)
Pullsync creates an eternal log of migration operations at /root/migration.log. These have entries in the format $(date)==$operation==$pullsyncdir==$username, where $operation is the type of sync performed (initial/email/final/mysql/etc), and $pullsyncdir is the main directory where the pullsync logs for that operation can be found.
Pullsync stores is information in a uniquely named directory in /home/temp/, both on the source server and the target server. These have a clear timestamp, in the format /home/temp/pullsync.$(date +%F.%T). The last pullsync run will have a symlink to it from /home/temp/pullsync/. You can likely look in there for in-progress migration information.
If the pullsync did not connect to a remote server, then it will be called /home/temp/noop-pullsync.$(date +%F.%T). These folders are generated only when doing local operations like site testing, reply generation, or DNS checking.
This file has a full log of all of the printed output from a pullsync. Use this file to see what pullsync and the tech performing the migration saw.
less -r /home/temp/pullsync/pullsync.log
If certain errors were encountered during pullsync, fatal or not, they will be added to error.log. These errors are more geared towards warnings to the technician of things to address post-sync, like changing the SSH port to match the source server, or informational output of changes made to make the target match the source, such as if sites were suspended on the source server and they were suspended on the target server to match.
This file contains the summary of errors detected at the conclusion of an initial sync. These will often include references to other log files and grep commands you can execute to get data from them.
cat errors_of_note.txt
These two files, versionsLocal.txt and versionsRemote.txt, have LAMP version output from both servers, as well as cPanel/modsec/EA versions, and hardware details (memory, core count, and processor class).
This file contains the output of php -m and php -i from the remote machine, for future comparison.
df.txt contains the output of df -P /home/ | tail -1 from the source server. Sizes are listed in KB. repquota.a.txt has the output of repquota -a from the source server. This can be parsed for source disk usage per-account, if quotas are enabled.
The list of cPanel usernames used during the pullsync run. If a user isn’t in this list, that doesn’t mean it wasn’t migrated. Check the eternal log at /root/migration.log to see if it was part of a different pullsync run. If its not there, it may have also been migrated manually without pullsync.
If there were collisions detected with pre-existing users (you would know from checking error.log), a list of the issues and a summary of the domains can be found here. This includes the accounting.log entries from cPanel’s creation of the domain, the account’s owned domains, and the DNS for the sites.
The missing*.txt files identify certain items on the source server that are outside of cPanel and/or not present on the target server. They include DNS zones created outside of cPanel (missingdnszones.txt), apache vhosts that do not have a matching cPanel account (missingvhosts.txt), linux users that are not cPanel users (missinglinuxusers.txt), enabled services that are not enabled on the target server (missingservices.txt), and processes listening on public ports are not listening on the target server (missinglisteners.txt). These are, again, warnings to the tech running the script to address these items post-initial.
This is the 'traditional' DNS check output for the sites involved in the migration. This can be leveraged to see what sites were resolving where, and using which nameservers, at the start of the sync.
There are additional files created by the script that split this file up into groups of domains that resovle to the source server, the target server, resolve elsewhere, or do not resolve at all (these files are aptly named in the same directory, source_resolve.txt, target_resolve.txt, not_here_resolve.txt, and no_resolve.txt.
A log folder is created with individual logs for every user operation performed in the sync. The files are appropriately named for the distinct stages: pkgacct.*.log, restorepkg.*.log, and rsync.*.log. Some useful commands to check for errors:
Check for bad mysql passwords or databases restored with alternate names:
grep 'Mysql::_restore_' /home/temp/*/log/restorepkg*log
Check for completely failed mysql restores:
grep 'DBD::mysql::db do failed' /home/temp/*/log/restorepkg*log