Hi!
I have been using XIBO CMS 1.7 on Fedora23 64bit for a few years without a problem. Recently updated to Fedora26 64bit and XIBO stopped working because of PHP7 incompatibility. A patch which I found googling did not help, latest XIBO 1.8.2 still does not support PHP7 and I opted to Docker install.
First I tried migrating from 1.7 to 1.8.2 docker with remote MYSQL and using different port 8081:80 following the instructions about cms-remote-mysql - all goes fine, but there is no access to web CMS from firefox, precreated empty DB in MariaDB server remains empty though /opt/xibo/shared/backup/import.sql is renamed to …done. LOG file appears with “MySQL didn’t start in the allocated time” in it. From terminal I access the DB server with the account specified (mysql -u **** -p ***), all permissions for /opt/xibo/ are set to 777.
I dropped the idea to migrate from 1.7 and attempted a fresh 1.8.2 docker install with custom port 8081:80 as Apache is running on port 80 of the CPU. All goes well, but firefox on the same CPU gives “connection reset” when attempting to connect to web CMS on localhost:8081 or 127.0.0.1:8081
Selinux is off. The containers list is:
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c79bd59e5129 xibosignage/xibo-cms:release_1.8.2 “/entrypoint.sh” 6 minutes ago Up 6 minutes 0.0.0.0:8081->80/tcp xibo_cms-web_1
b88a2ea42ccf xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh” 6 minutes ago Up 6 minutes 0.0.0.0:9505->9505/tcp, 50001/tcp xibo_cms-xmr_1
36743139c546 mysql:5.6
The only change in custom-ports.yml and docker-compose.yml is
ports: - “8081:80”
In config.env I input MYSQL password, tried also with commented #CMS_SERVER_NAME=cms.example.org
The containers can be accessed from terminal, file structure looks OK, but folders in /opt/xibo/shared/cms/web contain no files.
While performing these tests I used the following commands from within /opt/xibo folder:
docker-compose -f cms_custom-ports.yml up -d
docker-compose stop
docker-compose down
I noticed that when containers were created for the first time there was some download activity. After deleting the containers, the recreation went on without download. How can I delete the backup and download the installation again?
And idea where to look for a clue to the problem of web CMS not responding?
So on the import/upgrade scenario, you shouldn’t pre-create any databases. The MySQL container should not exist, and it’s shared/db folder should not exist either.
I’d try a full reset at this stage.
docker-compose -f cms_custom-ports.yml down
rm -r shared/db
Ensure your database backup is then in shared/backup/import.sql
docker-compose -f cms_custom-ports.yml up -d
Once the containers come up, are files created in shared/db?
DB ‘digsign’ does not exist on the MariaDB server working on port 3307 of the same CPU, user ‘routers’ from localhost and from % has full DB admin rights.
----docker-compose.yml---- same as —cms_remote-mysql.yml—
version: “2.1”
Create containers:
[root@ruters xibo]# docker-compose -f cms_remote-mysql.yml up -d
Creating network “xibo_default” with the default driver
Creating xibo_cms-xmr_1 …
Creating xibo_cms-xmr_1 … done
Creating xibo_cms-web_1 …
Creating xibo_cms-web_1 … done
db container is not created, nor /opt/xibo/shared/db folder:
[root@ruters xibo]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d56c662a7527 xibosignage/xibo-cms:release_1.8.2 “/entrypoint.sh” 56 seconds ago Up 56 seconds 0.0.0.0:8081->80/tcp xibo_cms-web_1
bf9b9f899899 xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh” 57 seconds ago Up 56 seconds 0.0.0.0:9505->9505/tcp, 50001/tcp xibo_cms-xmr_1
[root@ruters xibo]#
I did not use Your suggestion to create the containers with docker-compose -f cms_custom-ports.yml up –d as it would probably create db container following
services:
cms-db: …
After a few minutes LOG file appears in shared/backup with text: “MySQL didn’t start in the allocated time” import.sql is renamed to import.sql.done
/opt/xibo/shared/cms/custom and /opt/xibo/shared/cms/web/userscripts & theme/custom are created, all empty.
No DB is created in the MariaDB server.
After a few minutes more: /opt/xibo/shared/backup/db/latest.sql.gz is created, inside there is an empty latest.sql file
It seems there is no access to the external DB from within XIBO container. The peculiar thing about my installation is non-standard mysql port 3307 – it is declared in the docker config, but who knows . . .
Any idea how to check communication to DB server - in log files, with some command? From within the container is ‘localhost’ transferred correctly to the external DB server?
I have not attempted a fresh install today.
Thanks in advance.
I had missed that you are using a remote MySQL server.
So in that case, the docker-compose.yml and cms_custom-ports.yml files play no part and can even be removed to save confusion.
The only file we’re interested in is config.env (based on the remote mysql template), and cms_remote-mysql.yml.
Your MySQL hostname is the problem. MySQL cannot be running on “localhost” as the container sees it. The container runs on an isolated network separate to your host machine. You’ll need to specify the IP address of your MySQL server, and ensure that the MySQL server is listening on the network.
So for example, if your MySQL server is listening on 192.168.0.10, port 3307, then those are the values you would need to put in to the config.env file. By default, MySQL doesn’t bind to any network interfaces, so you’d need to amend your MySQL server configuration to allow that, and then protect connections to it with appropriate firewall rules.
You are correct that before the import can succeed, you also need to create an empty database with the name you’ve chosen (digsign) and ensure that the username and password you’ve given are permitted to access that database, from a remote location. So your grant will need to be for 'routers'@'%' rather than 'routers'@'localhost'.
The digsign user should not be a full database admin. It only needs access to your Xibo database and so that’s what it should be granted access to.
I think I found the cause of the problem: no connection to host IP from within the container. And naturally no connection to remote MySQL from within the container. I guess there is also no connection from host CPU to container on TCP:8081 port. Below is the output from some commands issued from within web container:
root@24d19d056402:/# route | awk '/^default/ { print $2 }'
172.18.0.1 - this is the IP to contact the host, but no ping to this IP and to host LAN or WAN IP:
On https://forums.docker.com/t/accessing-host-machine-from-within-docker-container/14248/14 I found some tips (about Mac):
Shall I look for a way to configure connection from within container to host network? The posts in the forum (linked above) suggests that docker-compose.yml should contain this configuration:
(example)
docker network create -d bridge --subnet 192.168.0.0/24 --gateway 192.168.0.1 dockernet
version: '2’
services:
db:
image: some/image
networks:
- dockernet
networks:
dockernet:
external: true
You should definitely be able to connect to the host from inside a container:
$ docker exec -ti xibodocker_cms-db_1 bash
root@536c684412d7:/# ping 192.168.0.151
PING 192.168.0.151 (192.168.0.151): 56 data bytes
64 bytes from 192.168.0.151: icmp_seq=0 ttl=64 time=0.147 ms
64 bytes from 192.168.0.151: icmp_seq=1 ttl=64 time=0.086 ms
^C— 192.168.0.151 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.086/0.116/0.147/0.031 ms
root@536c684412d7:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=55 time=20.796 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=17.801 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=18.587 ms
^C— 8.8.8.8 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 17.801/19.061/20.796/1.268 ms
root@536c684412d7:/#
You can see there my connecting to a CMS container, and being able to ping both the host and the public internet. That’s all with the shipped docker-compose files. docker-compose will have already created a bridged network as part of the containers setup - so there’s no need to add a second one. It happens by default:
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
c4eeb4d5dfee bridge bridge local
6df45ce6d7e9 host host local
b0fd7044df02 none null local
6d4e4a190a22 xibodocker_default bridge local <<<<<<<<<<<<<<<<
The link you give is regarding Docker on Mac. Are you running on a Mac? I thought you were on Fedora26? Docker on Mac is much like Docker on Windows and involves an additional VM so there can be complications in that area, but if you’re running on Linux, then that shouldn’t be an issue.
My strong suspicion is you have a firewall in there somewhere blocking that traffic. I know ufw on Ubuntu logs dropped packets to syslog on the host. Perhaps your firewall does too?
If you’re absolutely certain you don’t have an issue with a firewall, please restart the docker service on the host machine. That will recreate all the iptables rules that are required to get Docker connectivity working, incase something has modified those since the service was last started. Then restart the containers, check connectivity from container to host, and if that’s working, then you can do a full reset as before and import your data.
There should have been a firewall problem which I think is now addressed, but still no connection between host and container. As I work from the host, I ignored Xibo configuration_adjustments guidelines to treat inbound ports 80 & 9505.
I use Shorewall 5.0.14 firewall and followed the instructions on http://shorewall.org/Docker.html + enp2s0 172.17.0.0/12 in masq file as suggested in https://serverfault.com/questions/579726/docker-shorewall
Then recreated the containers:
[root@ruters xibo]# docker-compose -f cms_custom-ports.yml down
[root@ruters xibo]# ifconfig docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 - docker0 interface still exists
[root@ruters xibo]# docker-compose -f cms_remote-mysql.yml up –d
[root@ruters xibo]# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f2376a56f3a0 xibosignage/xibo-cms:release_1.8.2 “/entrypoint.sh” 7 minutes ago Up 7 minutes 0.0.0.0:8081->80/tcp xibo_cms-web_1
6143dce65902 xibosignage/xibo-xmr:release_1.8.2 “/entrypoint.sh” 7 minutes ago Up 7 minutes 0.0.0.0:9505->9505/tcp, 50001/tcp xibo_cms-xmr_1
[root@ruters xibo]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 95.158.164.1 0.0.0.0 UG 100 0 0 enp2s0
95.158.164.0 0.0.0.0 255.255.252.0 U 100 0 0 enp2s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c137ae129f0a
Please can you test if you can ping from the container, to your host IP address as a first step.
If you still can’t, then please temporarily disable Shorewall completely, restart the Docker service, and then try again. If you can then ping from the container to the host, the firewall is still the issue.
Solved! Thanks for the tip, it was really a firewall problem.
To those who might be using Shorewall, the working setup below is a bit different from the documentation on http://shorewall.org/Docker.html :
/etc/shorewall/shorewall.conf: DOCKER=Yes
/etc/shorewall/zones: dock ipv4
/etc/shorewall/policy:
dock all ACCEPT
$FW dock ACCEPT
loc dock ACCEPT
/etc/shorewall/interfaces: dock br+ - dhcp
Last record is the difference: the bridge interface br-***** should be routed, not the default docker0 interface as XIBO container setup creates this bridge and uses it to connect to the host. My mistake was that I routed docker0.
br+ better be defined with option “dhcp”, not “bridge” which does not allow “+” in interface name and would require bridge name check and interface name editing after each docker restart.
To me it is not clear how library files are managed. In the DB the library is defined on /var/www/cms/library/ inside the container, same files appear in /opt/xibo/shared/cms/library on the host. Guess the container location is a link to the host location where the files are really placed.
The docker-compose file maps parts of your local filesystem (for example /opt/xibo/shared/cms/library) inside the container. These are called volumes in docker.
It gives you a clean separation between “user data” and application.