I completed the following steps and I think they were fine:
copied over library files from previous install
truncated the log file
exported the database from the previous install
copied the database into the new shared/backup/import.sql location
I then brought the 3 containers up, with docker-compose, and it seemed to be fine. Then I connected to the mysql container to run the 3 additional SQL commands as in the instructions.
The log on my xibo-web container reveals a possible issue. However I am unsure where I can find further log information to help diagnose or what I may have done incorrectly.
Waiting for MySQL to start - max 300 seconds
MySQL started
Attempting to import database
Importing Database
Configuring Database Settings
Setting up Maintenance
DBVersion
94
Updating settings.php
Configuring Backups
Configuring Maintenance
Running maintenance
Starting cron
Starting webserver
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.6. Set the 'ServerName' directive globally to suppress this message
Waiting for MySQL to start - max 300 seconds
At this point I restarted the web container thinking that may help, as I couldn’t see anything on the http://localhost . I also browsed directly there using curl but it returns nothing.
MySQL started
DBVersion
120
Configuring Backups
Configuring Maintenance
Running maintenance
Unable to run upgrade step. Aborting Maintenance Task.Starting cron
Starting webserver
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.6. Set the 'ServerName' directive globally to suppress this message
Any advice is appreciated.
P.S. where is it possible to set ServerName? I did supply a value in config.env
You don’t need to specify a server name. It’s just a warning.
It looks to me as if it was in the process of running the upgrade, and you restarted it. See the Database Version number has gone up from 94 to 120.
I’d down the containers, bin what you have and start again. If you have a lot of layouts, or if your layouts are complex it can take from a few minutes to an hour or more to run.
Once the upgrade has completed, the webserver will start and you’ll be able to connect to the webserver.
Great, thank you for the guidance. Can I ask if I should see positive confirmation in the log once the web server does start? I’ve binned it all and started again but I don’t yet see any log message after
Starting webserver
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.18.0.6. Set the 'ServerName' directive globally to suppress this message
I am directly accessing it via curl command, on the same server (therefore no firewall), and I get nothing at all returned. Are there additional logs somewhere that would help me diagnose?
I’m running many other containers just fine and have modified my compose file so it exposes the container port 80 for traefik to pass external requests to. This works fine for all my other containers but I cannot figure out xibo.
I should be able to access the container directly but I cannot. Other containers do not behave this way.
I have tested both with the completely unmodified compose file from github (not working) as well as what I think should be modified to work with reverse proxy and neither is working.
Clearly I don’t understand something about what the xibo container is doing because my other apps work fine.
Strangely I can access the /admin page if I add that to the URL but it shows a 404. The other (document root) URLs result in gateway timeouts when accessed externally or blank result when accessing directly from the same server.
Can you first test then without importing your data to confirm the
containers work in your scenario as you expect. If that works then we can
try and figure out what the issue is
Thank you very much for the suggestion. I binned previous containers, got rid of the import.sql database, cleared the library, and re-ran docker-compose up -d with my custom configuration to work with traefik and all works like a charm. I see the login screen just as expected.
So I suppose this points to an issue with my database file or my library. For the import.sql I did confirm there were no USE db statements.
It does sound like there’s an issue there. If you’re happy to send a copy
of your data in we can try it here and see if we can sort it out. If you’d
like to do that we’d just need the import.sql file. I can PM you details of
how to send it in securely.
Dan has had a look at this this morning and it does look like a bug introduced in 1.8.3 - we’ve added a bug report for that.
The following applies to your database specifically. If you’re not @v60fan, then the following likely won’t apply to your database!
You should follow the guide to import your data. Once the upgrade fails, run the following SQL:
update setting set value="Off" where setting="FORCE_HTTPS";
ALTER TABLE media ADD createdDt DATETIME NULL, ADD modifiedDt DATETIME NULL;
Now log in to the CMS and you should be presented with the upgrade wizard. The step that was previously failing should now complete correctly.
You’ll find the process errors on one of the 1.8.3 steps near the end (ralated to adding the createdDt field for video media). You can safely skip that step.
The remainder of the upgrade should complete successfully.