#Dynmap webpage issues when using Docker PaperMC Image and Docker NGINX image for standalone WS

1 messages · Page 1 of 1 (latest)

charred jewel
#

Hello, I was just wondering if anyone has any experience with running dynmap within a docker container, using file persistence to share the web files over to an NGINX docker container, I have also set up a PHP container for the PHP usage within dynmap. The website is refusing to let me log in, refusing to let me register, and when disabling login in the config, the login screen appears anyway on reboot.

shut leafBOT
#

Thank you! Please provide any errors you are experiencing and upload your configuration.txt. Someone from our <@&801354402010628138> team will respond to help shortly. As a general reminder, everyone on our support team is a volunteer, please be kind!

charred jewel
#

My docker-compose file:

version: '3'

networks:
  npm-nw:
    external: true

services:
  nginx:
    image: 'nginx'
    ports:
      - "0.0.0.0:8123:8123"
    networks:
      - npm-nw
    volumes:
      - /srv/server/ferret-minecraft-skunkly/dynmap-webdata:/usr/share/nginx/html:rw
      - /srv/server/ferret-minecraft-skunkly/default.conf:/etc/nginx/conf.d/default.conf
    links:
      - php-fpm

  php-fpm:
    image: php:8-fpm
    volumes:
      - /srv/server/ferret-minecraft-skunkly/mc-server-data/plugins/dynmap/web:/usr/share/nginx/html:ro
    networks:
      - npm-nw

  papermc:
    image: 'marctv/minecraft-papermc-server:latest'
    ports:
      - 25565:25565
    networks:
      - npm-nw
    volumes:
      - /srv/server/ferret-minecraft-skunkly/mc-server-data:/data:rw
      - /srv/server/ferret-minecraft-skunkly/dynmap-webdata:/data/web:rw
    environment:
      - MEMORYSIZE=16G
shut leafBOT
charred jewel
#

This is what I get when I try to register or login. but with no response on the website:

php-fpm_1  | 172.28.5.5 -  22/Sep/2023:01:50:17 +0000 "POST /standalone/register.php" 200
nginx_1    | 192.168.0.119 - - [22/Sep/2023:01:50:17 +0000] "POST /standalone/register.php HTTP/1.1" 200 394 "http://192.168.0.17:8123/login.html" "[USERAGENT REDACTED]"
php-fpm_1  | 172.28.5.5 -  22/Sep/2023:01:50:33 +0000 "POST /standalone/register.php" 200
nginx_1    | 192.168.0.119 - - [22/Sep/2023:01:50:33 +0000] "POST /standalone/register.php HTTP/1.1" 200 394 "http://192.168.0.17:8123/login.html" "[USERAGENT REDACTED]"
php-fpm_1  | 172.28.5.5 -  22/Sep/2023:01:50:43 +0000 "POST /standalone/login.php" 200
nginx_1    | 192.168.0.119 - - [22/Sep/2023:01:50:43 +0000] "POST /standalone/login.php HTTP/1.1" 200 363 "http://192.168.0.17:8123/login.html" "[USERAGENT REDACTED]"
php-fpm_1  | 172.28.5.5 -  22/Sep/2023:01:50:52 +0000 "POST /standalone/register.php" 200
nginx_1    | 192.168.0.119 - - [22/Sep/2023:01:50:52 +0000] "POST /standalone/register.php HTTP/1.1" 200 394 "http://192.168.0.17:8123/login.html" "[USERAGENT REDACTED]"
#

I get outputs from NGINX and PHP but the website doesnt update whatsoever, no refresh, no error shown, like the button wasnt even clicked

noble jacinth
#

Never used it, but check the error.log of nginx, and the F12 developer console in your browser

charred jewel
#

Console output is clear, I will check the error log shortly

charred jewel
#

Yeah not getting much out of the error log

#

Just your typical worker process spitout

#

Tried to paste a little bit of it and apparently the automod doesnt like that haha

#

This, basically pretty normal NGINX worker process feed, nothing out of the ordinary

#

So, no errors being reported in error.log

#

Of course I get this from PHP in the tail when I click login ```php-fpm_1 | 172.28.5.5 - 22/Sep/2023:15:23:57 +0000 "POST /standalone/login.php" 200
php-fpm_1 | 172.28.5.5 - 22/Sep/2023:15:23:59 +0000 "POST /standalone/login.php" 200
php-fpm_1 | 172.28.5.5 - 22/Sep/2023:15:24:00 +0000 "POST /standalone/login.php" 200
php-fpm_1 | 172.28.5.5 - 22/Sep/2023:15:24:02 +0000 "POST /standalone/login.php" 200

#

but that doesnt seem to do anything

charred jewel
#

I appear to have resolved my issue, it seems to have derived somewhat from moving my dynmap files over from one server to the new one, the files that were generated beforehand seem to have an issue with being on a different system

#

by emptying my dynmap/ folder and allowing it to regenerate everything, the issue seems to be fixed

charred jewel
#

Okay, so update... it appears to be the login thats the problem

#

the registration and login screen appears to be whats causing the issue

#

It would appear to be the PHP elements that are failing

charred jewel
#

Yeah, I would suggest the issue lies in something being wrong with the PHPFPM container, which would imply its a me problem not a you problem haha

charred jewel
#

Alright, so I do have a question then, how does NGINX/PHP communicate back to the dynmap plugin when things happen, like registration or chat events

#

I need to link the right files

noble jacinth
#

Dynmap does that using a socket connect to the webserver afaik

#

But idk how it works

charred jewel
#

Socket! good to know

#

Its just about exposing certain ports between the two containers

#

I just need it to be able to communicate between the containers

#

If I could get a port number from the Devs that would make my job 100x easier than looking through the source code of dynmap for it

#

Slash slah, running a test on every port inside the container to see where dynmap is communicating

noble jacinth
#

Think it's just port 80 but not sure

charred jewel
#

80... interesting, I'll have a look

charred jewel
#

Ok, so I did some more digging

#

It was partially a permissions issue, which is now fixed

#

Dynmap uses files to communicate between the plugin and standalone webserver

#

and those files were being an absolute pain in my fluffy rearend when it comes to permissions

#

we managed to fix that... partially, but now a new issue has cropped up

#

everything works fine, chat, world view, e.t.c.

#

until... login enabled is set to true

#

then /standalone/update.php starts to return a 404

#

This only occurs when login enabled is set to true

#

furthermore the registration and login screen seems a bit... unstable?

#

First of all... when registering... clicking register gives no feedback to the user, it looks like nothing happened, although server side webauth.txt is created

#

and then login does work with that userid but we are left with the issue where the webclient reports Could not update map: Not Found and the console is full of 404 errors for update.php

#

And yes, before someone gets confused, this IS a standalone nginx webserver, I have just assigned the operating port to 8123 as there are other webservers using 80 and 8080 on this machine

#

Its not dynmap itself running this

charred jewel
#

Ok, so I know the issue now

(I dont know why it only occurs when login is enabled, but hey ho)

So dynmap is generating a php file called dynmap_access.php

Dynmap is assuming that the webserver is running on the same machine as itself

The dynmap_access.php file contains absolute paths to the web data that dynmap generates.

Because the webserver and dynmap are running on separate docker containers, they do not share the same file system

Dynmap is generating absolute paths within dynmap_access.php like /data/web/tiles/ or /data/web which is being picked up by nginx... and the lookup is failing as within the nginx container, the web files are at the absolute path /usr/share/nginx/html/

Nginx, does not contain the path /data/web

So now we have the issue where I'm not sure whether I can get dynmap to generate the dynmap_access.php file with differing paths to the webserver without breaking the file generation process

#

I am solving this issue by creating a persistent copy of dynmap_access.php and mounting that to the standalone folder... preventing dynmap from creating a new one and forcing it to use the altered version

#

Better solution thought of! And its fixed :D

Set dynmap configuration tilespath and webpath to /usr/share/nginx/html

Then mount that into nginx. Which means the config generated path is now correct.

noble jacinth
#

Nice that you figured it out on your own!

#

Good job