Open sseide opened 10 months ago
had a talk with Tildeslash about some problems around the migration from 3 to 4.
This problem here is rooted in the way MMonit does its update. For the update process the old configuration files from the 3.x directory are copied into the new (current 4.x) directory and the migration process starts than. Running interactive the "upgrade" program asks for a new license.
upgrade -p /config/mmonit-3.7.15-alpine/
Upgrading M/Monit from /config/mmonit-3.7.15-alpine to /opt/mmonit-4.0.0 ...
***WARNING*** please wait and DO NOT INTERRUPT the process (the upgrade can take some time if your database is large)
Reading license in '/config/mmonit-3.7.15-alpine/conf/server.xml'
Copying configuration files from /config/mmonit-3.7.15-alpine/conf/ to /opt/mmonit-4.0.0/conf/ ... done
Copying uploaded files from /config/mmonit-3.7.15-alpine/docroot/uploads/ to /opt/mmonit-4.0.0/docroot/uploads/ ... done
+------------------------------------------------------------------------------+
| LICENSE EXPIRED |
| |
| This is M/Monit version 4.0.0, released, November 17, 2023. Your license was |
| registred on April 15, 2015. Please renew your license to upgrade to this |
| version of M/Monit. |
| |
| When you renew your license, you'll get a year of updates for M/Monit. Once |
| that year is up, you can renew again or continue forever using the last |
| version of M/Monit you updated to. |
| |
| Please go to https://mmonit.com/user to renew your M/Monit license and |
| paste your renewed license below or enter q to abort this upgrade process. |
+------------------------------------------------------------------------------+
New License key>
Running manually you can enter your new license and the process goes on without problems.
Manually replacing the license inside the old server.xml
before starting the container / upgrade process solves this.
But with your automation the old 3.x license remains in the server.xml
of the old 3.x directory and is replaced after the (failed) upgrade process only inside the new 4.0 directory.
As this is a new case that did not happen for years i do not know how much to automate here or publish some workarounds in the README to do the update process manually...
i tried to upgrade my 3.5 version of the MMonit system to the current 4.0 version. During the upgrade the necessary database upgrade is not running therefor MMonit does no start up.
I think the problem is due to the order of the startup steps done. It seems the database upgrade is tried first and afterwards the new configuration files are created. Due to this the new MMonit 4.x upgrade script is executed with an invalid (old 3.x) license and does not run.
The second start up MMonit (after config file upgrade) is correctly using the new 4.x license and logs error messages only for having the wrong db table versions.
Full Log output of the startup: