Success switching from non-docker installation (Windows) to Docker (Ubuntu) - But Outdated Documentation

[pitoco02]

CMS: 3.1.4 (Windows server/IIS) to 3.1.4 (Ubuntu/Docker) (but it works with any other 3.* versions)

Hello everyone, I hope you’re doing well.

Well, I spent a few days trying to migrate a non-docker installation from Windows Server to a docker installation on Ubuntu 20.04.

I finally succeeded, but I want to warn you that the documentation below, for some reason, doesn’t work:

Xibo Digital Signage

The way I managed to migrate successfully was as follows:

1. Configure the config.env + docker-compose.yml files.
2. Create the folder structures:

shared
     |
     - backup
     - cms
         |
         - library

3. Move my library from Windows to my Linux installation over the network.

I used 7zip to compress my “library” folder to “.tar” and then recompress the “.tar” to “.gz” (gzip). (7zip link: https://www.7-zip.org/).

I moved my compressed library “library.tar.gz” to my Ubuntu server using the software “WinSCP”. (WinSCP link: WinSCP :: Official Site :: Download)

After that, I moved my library to the path of the installation container’s library (shared/cms/library) and extracted my files there.

Command to extract files on Ubuntu:

tar -xzf library.tar.gz

4. Importing the database from the non-docker installation into the Docker container.

After several attempts to do what was mentioned in the documentation, with no success regarding importing the old database by putting it in the “backup” folder with the name “import.sql”. That simply dosen’t work… even the file change the name after all to “import.sql.done”, but it do nothing, it do not import the data to the Databse container.

I gave up and did it manually:

I dumped my old DB to “import.sql”.

Then i started my “cms-db” container, accessed it via MySQL Workbench (you can do it via phpmyadmin or command line as well), and imported the database “import.sql” data to it manually.

5. Now it’s time to run the commands to standardize the “setting” table:

The documentation states that we should run these commands:

UPDATE `setting` SET `value`="/var/www/cms/library/", userSee=0, userChange=0 WHERE `setting`="LIBRARY_LOCATION";
UPDATE `setting` SET `value`="tcp://cms-xmr:50001", userSee=0, userChange=0 WHERE `setting`="XMR_ADDRESS";
UPDATE `setting` SET `value`="Apache" WHERE `setting`="SENDFILE_MODE";

Even after running these commands, the CMS won’t work.

What I did to work around this was:

• Run a Xibo database in Docker →
  dump only the settings table from this Docker database →
  truncate the settings table of my old non-docker database →
  import the settings table from the Docker database to this non-docker database.

Then the CMS worked. All my library is now in perfect condition, and the CMS is completely migrated from one environment to another.
After that, I just updated the fields of this settings table to match the configurations of the old table (without touching the sendfile mode, XMR, or library path columns).

What needs to be done now, but I haven’t had time yet, is to compare field by field to validate which other changes in the settings table are necessary because I have already validated that there must be something else beyond these three changes mentioned in the documentation:

UPDATE `setting` SET `value`="/var/www/cms/library/", userSee=0, userChange=0 WHERE `setting`="LIBRARY_LOCATION";
UPDATE `setting` SET `value`="tcp://cms-xmr:50001", userSee=0, userChange=0 WHERE `setting`="XMR_ADDRESS";
UPDATE `setting` SET `value`="Apache" WHERE `setting`="SENDFILE_MODE";

Hi @natasha! how are you?
do you have any more up-to-date documentation regarding this switch from a non-docker environment to a docker environment?
I think it’s of great value… because I haven’t seen anyone successfully migrate a newer version of CMS from a custom installation to Docker.
Thanks everyone!!

[natasha]

Hi Paulo,

This is the most up to date documentation we have and so I have checked this with the team who tell me that they use this route almost on a weekly basis with success.
They do offer up the following advice “if the “import.sql” is changing to “import.sql.done” then the script is doing something with that. At a guess it would be the sql file has a USE statement in it so its creating a new database other than the one we are expecting to use, for example.”

Do let us know how you get on!

[pitoco02]

Hi Natasha,

Thank you for responding.
I have tested thoroughly and can guarantee that there is no USE or CREATE DATABASE command or any other command that could indicate which database should be used or create a new database.
Additionally, I have access to the container and can confirm that no other database is created other than the default container DB (without any data from my “import.sql”).

I know that the documentation only mentions the USE command. Should the CREATE DATABASE command be added? Because I’m not using that command either… Could that be the problem? Can you please check with your team?

In fact, it only renames the file to “import.sql.done,” but nothing else. The data is not imported.

I will continue testing here and will keep you informed of any progress.

Best regards,

[natasha]

Hi Paulo

I have checked with the team and they confirm that there should not be a CREATE DATABASE.There must only be the shared/cms/library and shared/backup/import sql file. If there is a shared/db then it will not work.

The other suggestion they have is if the MYSQL_PASSWORD in config.env has special characters in it you will need to use a long alpha-numeric password as set out in the comments.

If you send over the container logs from when you up the container for the first time, that will help identify what the issue is.

I hope that helps!

[pitoco02]

Update:
I managed to make the import.sql work, but in a different way…
I standardized the settings table BEFORE creating the import.sql file.

Basically, I made a copy of my database, standardized the settings table, and then exported it to the “import.sql” file (without the ‘use’ or ‘create’ command).
This way it worked.

When I talk about standardizing the settings table, this is the procedure I followed:

@pitoco02

What I did to work around this was:

dump only the settings table from a Xibo Docker database →
truncate the settings table of my old non-docker database →
import the settings table from the Docker database to this non-docker database. →
set my custom configs to this new settings table (without changing those 03 settings of documentation)

[pitoco02]

Hi @natasha
I was able to migrate a custom install to Docker.
But, it keeps trhowing this errors:

Call to undefined function Xibo\Factory\__() and user not found

(Its in portuguese becouse it avoid me from edit anything in the settings page:

Theres anything that i can do to resolve this?

[pitoco02]

Updating: about the error “User Not Found”
I could manage the settings and find the problem.
I forgot to set the defautl system user on the table settings database:

now the problem is this:

[pitoco02]

Another thing is: the client dosen’t download the content… do i have to set anything more?

Tks!

[pitoco02]

Updating: The problem with the docker CMS dont download the content is the self-signed certificate.
I found that documentation some time later haha:

Xibo Digital Signage