search

pterodactyl / panel

Pterodactyl® is a free, open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to end users.
https://pterodactyl.io
Other
6.81k stars 1.74k forks source link

Pterodactyl in docker breaks in 1.2.0 #2961

Closed fayeinmay closed 3 years ago

fayeinmay commented 3 years ago

Background (please complete the following information):

Describe the bug In 1.2.0 running the docker wings container will result into the following error on startup: failed to create pterodactyl system user error=open /usr/lib/os-release: no such file or directory

when linking os-release to the container the startup results into the following error:

Stacktrace: exec: "useradd": executable file not found in $PATH github.com/pterodactyl/wings/cmd.rootCmdRun github.com/pterodactyl/wings/cmd/root.go:173 github.com/spf13/cobra.(*Command).execute github.com/spf13/cobra@v1.1.1/command.go:854 github.com/spf13/cobra.(*Command).ExecuteC github.com/spf13/cobra@v1.1.1/command.go:958 github.com/spf13/cobra.(*Command).Execute github.com/spf13/cobra@v1.1.1/command.go:895 github.com/pterodactyl/wings/cmd.Execute github.com/pterodactyl/wings/cmd/root.go:369 main.main command-line-arguments/wings.go:8 runtime.main runtime/proc.go:204 runtime.goexit runtime/asm_amd64.s:1374

Might be due to dependency bump https://github.com/pterodactyl/wings/commit/a4c8b8714bf9c8fdc491b19f1dea26d268305578 or due to Dockerfile edit: https://github.com/pterodactyl/wings/commit/fafda283b1e69f83bfa1dbb705e358b575ced86a

To Reproduce Steps to reproduce the behavior:

  1. Create a 1.2.0 docker version of the wings/panel
  2. Start the containers

Expected behavior Not erroring out on startup

DarthShmev commented 3 years ago

I am experiencing the same issue as well.

matthewpi commented 3 years ago

This is probably due to the change of switching the final container to busybox. But this brings up another question about if the containers are actually running under the proper user if the user is just created within the wings container itself and not on the host system.

matthewpi commented 3 years ago

This should be resolved by pterodactyl/wings@ee0c7f0

Use ghcr.io/pterodactyl/wings@sha256:ba741be73b6ca376fd55798f2d6381d2308178cb34b6f398bcb4fdd9e102a1d0 as your Docker image for running wings. (This image is v1.2.0 with the fixes applied to it and hash-pinned to prevent people from running develop)

With these changes you should create the pterodactyl user manually on the host system for better security, this will prevent any potential overlap with other system users, ensuring that the server containers don't have any access that they shouldn't. useradd --system --no-create-home --shell /usr/sbin/nologin pterodactyl Then get the uid using id -u pterodactyl and gid using id -g pterodactyl and set the WINGS_USERNAME, WINGS_UID, and WINGS_GID environment variables with those values.

AeonLucid commented 3 years ago

I have the same issue. Switching to the hash given by @matthewpi resolves that issue but creates another one saying failed to load server configurations error=Get "https://MY_PANEL/api/remote/servers?per_page=50": x509: certificate signed by unknown authority. Even though it's a valid SSL certificate (from let's encrypt).

Was it noted anywhere that 1.2.0 docker would be such a breaking change?

fayeinmay commented 3 years ago

@AeonLucid That's another issue unrelated to pterodactyl, LetsEncrypt has a new CA IIRC and thus they break sometimes.

AeonLucid commented 3 years ago

@JanDevDE Rolling back to 1.1.3 fixes it for me, which makes me think 1.2.0 broke it. SSL breaking "sometimes" seems rather odd.

fayeinmay commented 3 years ago

@AeonLucid I'd say open another issue for it then.

matthewpi commented 3 years ago

Rolling back to 1.1.3 fixes it for me, which makes me think 1.2.0 broke it. SSL breaking "sometimes" seems rather odd.

Try using ghcr.io/pterodactyl/wings@sha256:eab6b8d6b7bd2a86dab0c1ac97e3cd6300db5eed314a9a30314e65b8d3cdc7da for the wings container. This updated busybox which may or may not fix the problem.

DaneEveritt commented 3 years ago

Should have been fixed in 1.2.1 or 2 or 3.

Dr3nz4r commented 3 years ago

Should have been fixed in 1.2.1 or 2 or 3.

Seems to still be broken for me running 1.2.3

fayeinmay commented 3 years ago

@Dr3nz4r Works for me on 1.2.3. You got the same error as I posted?

matthewpi commented 3 years ago

Seems to still be broken for me running 1.2.3

If you are having the SSL error, make sure you have the ssl mount in your docker-compose.yml https://github.com/pterodactyl/wings/blob/develop/docker-compose.example.yml#L25

Dr3nz4r commented 3 years ago

Seems to still be broken for me running 1.2.3

If you are having the SSL error, make sure you have the ssl mount in your docker-compose.yml https://github.com/pterodactyl/wings/blob/develop/docker-compose.example.yml#L25

Will try that. Thought (as I use letsencrypt) that the ssl one then becomes optional (doh)

matthewpi commented 3 years ago

Will try that. Thought (as I use letsencrypt) that the ssl one then becomes optional (doh)

That mount is for trusted certificates, it has nothing to do with the certificate used.

Dr3nz4r commented 3 years ago

Will try that. Thought (as I use letsencrypt) that the ssl one then becomes optional (doh)

That mount is for trusted certificates, it has nothing to do with the certificate used.

Thanks, SSL issue is resolved now.

stuck with another issue now. I guess I'll debug a bit and possibly open another issue here then.


WARN: [Jan 27 18:57:50.015] unable to pull requested image from remote source, however the image exists locally err=Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:52127->[::1]:53: read: connection refused image=debian:buster-slim

INFO: [Jan 27 18:57:50.033] creating install container for server process install_script=/tmp/pterodactyl/a2a0108d-6594-4c9b-97e2-3dc5c32e7167/install.sh server=a2a0108d-6594-4c9b-97e2-3dc5c32e7167
ERROR: [Jan 27 18:57:50.145] failed to complete server re-install process error=Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /var/lib/pterodactyl/volumes/a2a0108d-6594-4c9b-97e2-3dc5c32e7167 server=a2a0108d-6594-4c9b-97e2-3dc5c32e7167

Stacktrace:
Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /var/lib/pterodactyl/volumes/a2a0108d-6594-4c9b-97e2-3dc5c32e7167```
DaneEveritt commented 3 years ago

That is fixed on develop.

Sabinno commented 3 years ago

I'm getting the SSL certificate issue. FATAL: [Feb 12 16:41:47.957] failed to load server configurations error=Get "https://panel.argonaut.network/api/remote/servers?per_page=50": x509: certificate signed by unknown authority I have confirmed that, in the wings docker-compose.yml, /etc/ssl/certs is mounted; here's my docker-compose for wings, in fact: https://paste.centos.org/view/8580e436 I have confirmed that /etc/pterodactyl/config.yml is pointing to the correct certificate pair location generated by Let's Encrypt. Using --ignore-certificate-errors (as I clearly attempted to do) results in a totally different error regarding requiring an Authorization header. I am quite certain, after a few hours of troubleshooting and verifying configurations, that this is not a configuration issue, but a bug. I am using :latest tags on both panel and wings as of time of writing.

Dr3nz4r commented 3 years ago

I'm getting the SSL certificate issue. FATAL: [Feb 12 16:41:47.957] failed to load server configurations error=Get "https://panel.argonaut.network/api/remote/servers?per_page=50": x509: certificate signed by unknown authority I have confirmed that, in the wings docker-compose.yml, /etc/ssl/certs is mounted; here's my docker-compose for wings, in fact: https://paste.centos.org/view/8580e436 I have confirmed that /etc/pterodactyl/config.yml is pointing to the correct certificate pair location generated by Let's Encrypt. Using --ignore-certificate-errors (as I clearly attempted to do) results in a totally different error regarding requiring an Authorization header. I am quite certain, after a few hours of troubleshooting and verifying configurations, that this is not a configuration issue, but a bug. I am using :latest tags on both panel and wings as of time of writing.

is /etc/ssl/certs mounted to /etc/ssl/certs? that's a requirement

Sabinno commented 3 years ago

is /etc/ssl/certs mounted to /etc/ssl/certs? that's a requirement

Yes, certainly. Take a look at my wings docker-compose.yml that I linked; you can see that for yourself.

Additionally, I'm running CentOS 8, if that helps. I've verified that SELinux is not throwing any errors, and the same thing occurs in permissive mode.