![]() The only odd thing was that each year had to be separately updated for the recovered stats to render. I have AllowToUpdateStatsFromBrowser enabled for the domain in question, so I updated it from the Awstats report itself. There were the records for the missing months. SCP'd to the new (Virtualmin) server and uploaded those. ![]() txt files for the months with missing data. SCP'd into the old server (I still have backup files there).ĭownloaded /backup-_/homedir/tmp/awstats/ssl/ to my computer. This is what I did to recover the data, step by step. Those months correspond to the time during which I'd forced SSL on the site, prior to migrating it to Virtualmin. I just tried it on a different domain than the one I sent you, Jamie, that was missing data for the following months: ![]() Okay, my last idea did in fact work as a post-migration solution to recover the data for the months for which the stats were missing from Awstats due to cPanel's practice of separating the reports into SSL- and non-SSL versions. How to merge the historical records during the migration itself is a project for someone much smarter than I am. One would just look for the empty months in Awstats and replace only those files.Īlso, if the site were switched to SSL mid-month, the data for the time prior to the switch for that month would be lost but that would be better than all the traffic data being lost. Of course, this will only work (if it works at all) if all traffic were forced to SSL pre-migration, resulting in zero traffic in the files because they were for the non-SSL domain. On the Virtualmin server with those in the cPanel migration subdirectoryīackup-_/homedir/tmp/awstats/ssl/ I think the workaround for this post-migration, assuming that the site forced all traffic to SSL, would be to replace the Submitted by JamieCameron on Sun, - 19:25 Comment #7 Please let me know if there's some way I can securely send you the file, and I'll be happy to do so. That's as far as I got with this before I had other things to do. So my hunch is that part of the problem may stem from the fact that cPanel splits the Awstats data into SSL and non-SSL versions. But if I copy it to the desktop, I can open it using any text editor. Windows neither errors out nor asks me how I want to open it. I cannot open that file while it's in the folder. \homedir\logs-ssl_log-Jun-2019Ĭontaining a single file of the same name as the folder. But if I copied the file to the desktop, I could open it with any text editor using "Open With." ![]() No options to open the file were offered, and no request to select a program to open it was made by Windows. If I tried "Open With" while the file was in its containing folder (using Win10 Pro), nothing happened. Awstats on cPanel treats SSL and non-SSL versions of sites separately, and I was unable to open some of the logs for the SSL versions after extracting the archive unless I copied the files to someplace outside their containing folders. The file is ~108MB.Īlso, I think I've narrowed down the problem a bit. Do you have a way for me to get it to you securely? Some of the code includes MySQL credentials used as part of a malicious activity tracking system that gathers information from multiple sites and compiles it into blocklists, so I don't want to just post a public link. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |