Closed johnjore closed 2 days ago
shawniverson
commented
4 days ago Again, updating v4 to the latest version before migrating would help alleviate some of these issues, so the wiki now includes that step. You can go ahead and correct the MailScanner Version Number in the configuration file.
johnjore
commented
4 days ago Oh dear. Wish the restore had a warning when doing a restore from a non-supported version. Created a PR to include eFa-Version in backups. Next step would be to enhance the restore to do a compare and display some form of warning if doing a non-tested/supported restore.
johnjore
commented
4 days ago Hm.. Taking a stab in the dark here, but I very much doubt these error messages are related to the upgrade as it still happens after upgrading the source to 4.0.4 and fresh restore and the datestamp of all entries with NULL as the dates are from 2020, so a very long time ago.
Line 54/55 from mailwatch_milter_relay.php:
$result = dbquery("SELECT id from `maillog` where messageid='" . $message_id . "' LIMIT 1;");
$smtpd_id = $result->fetch_row()[0];From the error message, its very unhappy if message_id NULL. I have about 2700 entries without a messageid (blank) and 80 that are NULL and its these 80 I think its very unhappy about.
PHP Warning: Trying to access array offset on value of type null in /usr/bin/mailwatch/tools/Postfix_relay/mailwatch_milter_relay.php on line 55
Edit: After changing the NULL values to empty strings in the database, its not longer triggering the error for those lines. No idea why there were 88 with NULL as the messageid. There are now about 2800 entries without a messageid. Not sure if that is a good or bad things... ?
Its now "only" triggering on lines 86 and 91, which I think is scraping /var/log/maillog? looking for entries with postfix/cleanup? and failing:
php[4105]: Warning: Trying to access array offset on value of type null in /usr/bin/mailwatch/tools/Postfix_relay/mailwatch_milter_relay.php on line 86
php[4105]: PHP Warning: Trying to access array offset on value of type null in /usr/bin/mailwatch/tools/Postfix_relay/mailwatch_milter_relay.php on line 91
php[4105]: Warning: Trying to access array offset on value of type null in /usr/bin/mailwatch/tools/Postfix_relay/mailwatch_milter_relay.php on line 91
php[4105]: PHP Warning: Trying to access array offset on value of type null in /usr/bin/mailwatch/tools/Postfix_relay/mailwatch_milter_relay.php on line 86Something doesn't seem right with your mailwatch_milter_relay.php. For example, lines 54/55 are lines 159/160 in the current version of MailWatch.
Can you compare your file with this one?
johnjore
commented
4 days ago Not even close. The copyright ended in 2018, so its donkeys old.
/*
* MailWatch for MailScanner
* Copyright (C) 2003-2011 Steve Freegard (steve@freegard.name)
* Copyright (C) 2011 Garrod Alwood (garrod.alwood@lorodoes.com)
* Copyright (C) 2014-2018 MailWatch Team (https://github.com/mailwatch/1.2.0/graphs/contributors)This is what RPM tells me it's done, but I cant seem to find the RPM locally in the rpmbuild folders, I.e. not built from SPECS, but would come from dnf/yum.
rpm -qa MailWatch
MailWatch-1.2.23-2.eFa.el9.noarchBuilt package from SPECS file and unpacked the RPM and it has the correct version.
rpm -qi MailWatch
Name : MailWatch
Epoch : 1
Version : 1.2.23
Release : 2.eFa.el9
Architecture: noarch
Install Date: Fri 28 Jun 2024 05:37:37 PM AEST
Group : Applications/Utilities
Size : 7617947
License : GNU GPL v2
Signature : RSA/SHA256, Tue 11 Jun 2024 07:34:44 AM AEST, Key ID 3e31c900141b6cd8
Source RPM : MailWatch-1.2.23-2.eFa.el9.src.rpm
Build Date : Mon 10 Jun 2024 12:42:03 AM AEST
Build Host : builder
URL : https://github.com/mailwatch/MailWatch
Summary : MailWatch Web Front-End for MailScanner
Description :
MailWatch for MailScanner is a web-based front-end to MailScanner written in
PHP and MySQL and is available for free under the terms of the GNU Public
License.rpm -q --changelog MailWatch
* Sun Jun 09 2024 Shawn Iverson <shawniverson@efa-project.org> - 1.2.23-2
- Additional cleanup for mtalog_ids
* Tue Mar 07 2023 Shawn Iverson <shawniverson@efa-project.org> - 1.2.20-1
- version 1.2.20
Install date is correct. My aarch64 VM did not exist on June 10'th, the build date, nor is it called "builder"
Looking at /var/cache/dnf/eFa5-release-6795dba078b006a7/repodata and unpacking the various gz files, I find an XML that references the file, but without enough metadata about the file (date, size etc) to know what it included.
Not so sure what has happened here, but the most interesting thing is that the package was built right after a change was made on June 9.
Any chance at all that something went wrong during the build of the package (because its a noarch, I would normally not need to build it for aarch64 platform) and its actually got the wrong files in it?!?
Edit: Downloaded RPM from https://mirror.freedif.org/efa-project/rpm/eFa5/centos9/release/, and had a looksy, and its the correct php script embedded.
johnjore
commented
4 days ago Rolled back my eFa4 appliance, to 4.0.3, and its the old version:
Restore process overwrote the correct and up-to-date version?
Update: Given how bad this has ended up, I'll rollback my eFa5 appliance to pre-restore of 4.0.3 and start over with a restore of the 4.0.4 and re-do all the non-eFa configuration (monitoring, UPS etc etc).
Anyone coming from a non-x64 platform (arm) dont have easy access to updated binaries and might not be running 4.0.4 when migrating to v5 and 9. Think the sooner the restore process does some version checking the better. As CenOS 8 Stream has gone EOL, I suspect a few will be upgrading in the not so distant future and might end up in the same mess I have.
Post Migration, (restore), /var/log/messages has a lot of warnings:
On eFa5 Server (after creating missing to_address):
Restore/migrated from:
I assume/suspect eFa Restore is missing some logic to handle restores from all/previous versions of eFa and makes some assumptions?
As per issue #2, a column was missing in a table post-restore.
I can probably add the "missing" steps if you can point me in the right direction, but suspect I might not be the only one upgrading from one version of eFa and restoring to a newer version?
Update: I've gone through the upgrade script for 4.0.4, but didnt see anything out of the ordinary?
PS. On "new" eFa5 server:
Not sure if this is intentional as the mailscanner.conf file is not restored from eFa4, but from the eFa5 install.