container not listening to provided container

[itzg]

container not listening to provided container

[itzg]

Rather than /data, the bungeecord image expects the config.yml to reside in the attached volume at /server. This section has a little more info:

https://github.com/itzg/docker-bungeecord#volumes

[olesien]

Hm yeh I did take a look at that earlier, however with little success. Can you give me a version of the one I pasted however probably working (all work just fine but the bungeecord one). It would be much appreciated :)

[itzg]

Luckily I already created an example in the https://github.com/itzg/docker-bungeecord/tree/master/docs directory.

[olesien]

What it looks like right now:
bungee-server:
ports:
- "25565:25577"
volumes:
- /home/timli168/bungee:/config.yml
environment:
EULA: "TRUE"
INIT_MEMORY: "1G"
MAX_MEMORY: "2G"

image: itzg/bungeecord

container_name: bungee

tty: true
stdin_open: true
restart: always

I also have had it: exactly as the one you showed (like that part), however having it output an error saying that /server/config.yml doesn't exist, and a bunch of others.

[itzg]

Have you created the file config.yml in your /home/timli168/bungee directory already? If so, the volume mapping would be:

    volumes:
      - /home/timli168/bungee/config.yml:/server/config.yml

Are you using docker-compose or docker stack deploy to deploy the compose file?

[olesien]

I'm using docker-compose.yml. I put it inside of timli168 and run the command docker-compose up -d

[olesien]

What I got when running it now (those two lines are the ones you did :P
https://gyazo.com/1fe5cb112308e747482eb01df6f1baec

[olesien]

What the docker-compose file looks like now:
https://justpaste.it/4ggcl
(spaces don't work inside of that website, they are spaced correctly)

[olesien]

Thanks a lot for helping me btw, this isn't exactly what I'm good at as you probably have noticed xD

[olesien]

What /home/timli168/bungee looks like:
https://gyazo.com/91444e6cc6975c1f47e47ebfd0682c76

[itzg]

It’s ok, I don’t use bungeecord that much so I have to re-learn how to use it each time.

[olesien]

Okay ;) Just take your time, I really do need this fixed though as I don't really want it unhealthy (when using bungeecord with itzg/minecraft-server image, it works, but it takes a while to start and also in minecraft, it looks like it does not work first time you check, but it does..)

[itzg]

I'm still working on a better example that closer matches your scenario. I was just clarifying that I'm a little slow to help with the bungeecord issue since I don't readily have examples other than the one in the repo.

[olesien]

No problem ;) How long do you expect it to take?

[itzg]

@olesien here is a more complete example with a lobby and three varying servers:

https://gist.github.com/itzg/fa64a1686dd5b4a2a768202676111ed1

FYI, rather than vary the port for each, I leave them all at the default 25565 and in the servers section here

https://gist.github.com/itzg/fa64a1686dd5b4a2a768202676111ed1#file-config-yml-L18-L34

I ensure the "hostname" matches up with the service name from the compose file.

[olesien]

Okay works now. What should I add to bungeecord so that it finds the plugin folder aswell?

[olesien]

Thanks for fixing it.. For some reason there is one really devastating issue: Everyone on the server is treated the exact same, so I can't do any things even though I have op and a group in pex that should allow me to do anything. docker attach does seem to work at first, as you do get info like for example when I type something in chat. Although you can type things and press enter, they don't register at all, like if I normally type "op olesien", it'll say so. However it doesn't (and I also don't get oped)

[olesien]

Okay so based on my understanding, it's something fucked up with the uuid or such

[olesien]

When trying it on my pc (this is just root access to a ubuntu server) I noticed a similar thing when testing with online mode still set to false (however only one server). I suppose this is caused by the fact that bungeecord does not give the information about the uuids, which makes the server think that it's running in offline mode. Any idea of a fix?

[olesien]

It did work just fine before sooo

[itzg]

Yeah, I remain confused about how bungeecord is managing user identity what with the requirement to set the backend servers in offline mode.

As far as working before, do you mean before using containers? Or during one of the steps above?

[olesien]

Before the steps above

[olesien]

Hm
Maybe it's because it's only able to like.. read config.yml and not be able to update anything else?

[olesien]

When running a normal bungeecord server on my pc, I can see that proxy.log.0.yml along with proxy.log.0.lck.yml get created. Maybe these need to be able to be updated?

[itzg]

Other than the volume mapping, the container isn't doing anything special with config.yml and I noticed in my case that bungeecord was able to create all the other files it needed in the /server path. If you docker exec into the bungeecord container and cd /server you'll see all the other files it created. FYI I added a volume declaration for /plugins and the startup script will copy of the contents of that into the bungee directory.

[olesien]

nvm not .yml xD

[olesien]

oh okay

[olesien]

The question is however, are these files inside of /server able to update themselves or do they rely on the specified volume to update and THEN copy the files?

[itzg]

Yes, the /server directory is a regular Linux directory inside of the container. The container startup script does pull down the latest version of bungeecord, so perhaps there's a bug in their code. That's only speculation, so when I get chance tonight or tomorrow I'll try out the "op" commands to see if I can learn more about bungee configuration.

[olesien]

AYE ;)
I fixed it

[olesien]

In order for bungeecord to be able to connect at all, offline mode needs to be set to false (you know this already). You do however also need to set bungeecord to true in the spigot config. Upon doing this, I got the error that ip-forwarding needed to be set to true in the config. Due to errors before you stepped into the picture, some bungeecord options were a bit... bugged (so this didn't work, I always had it set to true anyways). It is however set to off as default. And since I didn't think of it, it was set to false. Now why is this an issue? Well.. Because if you just connect normally with 25565 (or no port,, same thing), you actually go through lobby or whatever. And this is counted as Ip-Forwarding. It seems to work now ;)

[olesien]

There is one issue remaining though.. Docker attach is still very bugged. I am not sure but.. it might be because the servers have specificed port? So although it can still receive information from the servers, it has no idea where it's supposed to send the information like ("op olesien") and therefore not recieve anything like ("opped olesien")? This is an issue that I probably won't be able to solve on my own, so I'll probably need your help on this one.

[itzg]

That’s great to hear about the progress. The “op” scenario is something I can possibly help look at; however, since it used to work for you before can you provide a config.yml and server.properties (from server side) that used to work? What version and flavor of server jar were you using that worked?

[olesien]

With op scenario you mean the docker attach issue I suppose. I always use spigot and not bukkit or vanilla. (Vanilla is the one without plugins. Spigot is the one that works best with bungeecord). I can't really provide those two atm (server.properties is pretty irrelevant though). I am pretty certain that it is either something either with the ports or missing setting in docker compose (I remember something about tty = true for example, you can take a look at the top of this thread.)
Could you please try out yourself and see if it works for you? (With spigot preferably)

[itzg]

That's a good point -- I have been experimenting with vanilla backends, but not with spigot. I'll give that a shot and see if I can make any progress.

As for the "op scenario" I just meant where you mentioned

it has no idea where it's supposed to send the information like ("op olesien") and therefore not recieve anything like ("opped olesien")

Like you said, it might end up being a TTY/console type setting. To clarify, you're expecting to see that in the container logs or back in the Minecraft client view? Likewise, are you running the op command and others via the server console or within the client with a /op?

[itzg]

Aha, you provided exactly the right clue. I was able to see the same problem when I ran a container via docker-compose (vs a docker run) and the solution for me was adding the stdin_open: true such as this line

https://gist.github.com/itzg/9f97a77e3461116f024f7a2c9c64d03d#file-docker-compose-yml-L15

[olesien]

Good job! ;) Thank you very much for helping me with these issues even though you could have just not replied ;)