#@Danpiel can you do
1 messages · Page 1 of 1 (latest)
python -m pip install steamquery
cat <<EOF > query.py
from steam import SteamQuery
import sys
server_ip = str(sys.argv[1])
server_port = str(sys.argv[2])
server = SteamQuery(server_ip,server_port)
info = server.query_server_info()
print(str(info))
EOF
python query.py 127.0.0.1 15637
run this @bleak python
in bash
sec
see if you can get a response from the UDP query port with your server info
if an external tool is able to query it, then your server is running fine and your port forwarding at your router is correct
it means their website is calling that port @ your external IP (public, provided to you by your ISP), then your router is forwarding that request for that port to your internal IP of the host you configured, which is your actual server/system
and your firewall rules are fine, and your container is using hostnetwork
yes
you SHOULD be okay, in fact, you can probably remove the hostnetwork settings from your config
problem is that game port is not 15636
can you do docker rm d881 for me?
but random from 49152–65535
to prune that other dangling container
danpiel/gameservers:proton was ran and exited 4 hours ago
at container id d881
done, that was custom build Palworld )
go ahead and stop your enshrouded server container now
and prune it as well
you can also do docker container prune -y to prune exited containers
you should be fine to remove hostnetworking from your config
services:
enshrouded:
image: sknnr/enshrouded-dedicated-server:proton-latest
restart: unless-stopped
network_mode: host
ports:
- "15636:15636/udp"
- "15637:15637/udp"
environment:
- SERVER_NAME=Cheeseshroud
- SERVER_PASSWORD=
- GAME_PORT=15636
- QUERY_PORT=15637
- SERVER_SLOTS=16
- SERVER_IP=0.0.0.0
volumes:
- enshrouded-persistent-data:/home/steam/enshrouded/savegame
volumes:
enshrouded-persistent-data:
this is your current config
and you can drop network_mode: host
setting network mode to host will use a different CNI
You shouldn't need to change SERVER_IP=0.0.0.0 unless you've attached your container to multiple networks
but you haven't
using 0.0.0.0 tells the process to LISTEN to all ipv4 interfaces on the host
it will respond to literally any request on any interface
you're better off leaving it 0.0.0.0
in fact, don't set it to your public IP, because your public IP doesn't live on your host, it lives on your router
so the server won't LISTEN or respond to anything if you do that
this is dedicated server on OVH, ip is directly attached to the nic
no router in between
ok
leave it 0.0.0.0
so
container networks
docker/podman/etc use an overlay container network interface, think of it like OpenvSwitch if you've ever done virtualization
or bridge
containers live on a default network, and only share your host interfaces if you use hostnetworking
yes
ok, server started
that bridge doesn't have egress out of your host machine by default, unless you use --publish-ports or -p
I know how it works )
it's not a good idea to use hostnetworking unless you're rootless and need to bind ports < 1024
but even then you likely would have conflict with host services
these ports are specific to the game and I'm 100% sure they are not used
like for example if you were running a containerized dns service that uses port 53, it would conflict with services like systemd-resolved on your host and you'd have to change things
if you have dangling containers that bound that port as well, you'd have conflict issues
you started your container, can you do docker ps -a again?
that's I'm talking about, see the open ports inside container
and compare to ports on host
try configuring them to use a different port as a troubleshooting step
try using 30700 and 30701 as your server ports
udp
docker port d5bb as well
enshrouded:
image: sknnr/enshrouded-dedicated-server:proton-latest
restart: unless-stopped
# network_mode: host
ports:
- "30700:30700"
- "30701:30701"
- "30700:30700/udp"
- "30701:30701/udp"
environment:
- SERVER_NAME=Cheeseshroud
- SERVER_PASSWORD=qwe123
- GAME_PORT=30700
- QUERY_PORT=30701
- SERVER_SLOTS=16
- SERVER_IP=0.0.0.0
volumes:
- enshrouded-persistent-data:/home/steam/enshrouded/savegame
volumes:
enshrouded-persistent-data:```
changing config to the one
15636/tcp -> 0.0.0.0:15636
15636/tcp -> [::]:15636
15636/udp -> 0.0.0.0:15636
15636/udp -> [::]:15636
15637/tcp -> 0.0.0.0:15637
15637/tcp -> [::]:15637
15637/udp -> 0.0.0.0:15637
15637/udp -> [::]:15637```
ok, server restarted
inside the container, can you do lsof -i -P -n | grep 15636
If this doesn't work and it keeps binding the wrong port, i'll have you restart the docker daemon
with sudo systemctl restart docker (but dont do this yet)
nothing
okay tear down that container and prune it
restart the docker daemon and stand it up again
is your container using ports 30700/1 right now or the original ports?
you can grep for 30700 as well with lsof
restarted docker host, starting server
hm
This image updates game on every restart
yeah
You can use my updated container image if you want
I have instructions on using mine there
it's a generic proton-runner based on Proton GE 9.2
You can mount your savegame at /steamapp/savegame
I'm updating my runner image to include an optional steamcmd update on start for people who are used to doing everything all-in-one
it's not entirely ready for K8s out of the box
I am polishing the image for auto-install and the prefix builder, right now WINE yells at you if the prefix path isn't owned by you
which causes problems on k8s
but I do have it running on my k8s cluster
but the podman kube play DOES work.
since podman locally works different from k8s
I don't use podman, since docker does the same thing
k8s has seccomp profiles and assigns different namespace UID/GIDS
not by default )
I prefer podman because it uses podman kube play instead of docker-compose
if you install podman, you can run Deployment manifests OOTB
which does the same thing as compose locally
yeah
so if you wanted to install podman, yes, it will work OOTB (the manifests I have in the repo)
still no clue why game server binds itself to random
you can simply add your savegame mount in the deployment.yaml
and follow my instructions
up to you
I should have a tweaked proton-runner image today promoting from my dev to main branch that will be available in an hour or so if you want
then it should work with 1 single YAML/script and also work for k8s
ok, tried with podman, same thing happening ))
also you have typo in this linehttps://github.com/steamutils/proton-apps/blob/main/apps/enshrouded/manifests/run.yaml#L24
should be 15636
but podman uses default internal engine to run containers, not k8s
¯_(ツ)_/¯
updated the proton runner image, it includes install and update in it
every time the container restarts it will run the STEAMCMD_ARGS before starting proton
I pruned the working resources and updated the README's
you can try it with podman kube play
this should work out of the box as-is