felddy / foundryvtt-docker Goto Github PK
View Code? Open in Web Editor NEWAn easy-to-deploy Dockerized Foundry Virtual Tabletop server.
Home Page: https://hub.docker.com/r/felddy/foundryvtt
License: MIT License
An easy-to-deploy Dockerized Foundry Virtual Tabletop server.
Home Page: https://hub.docker.com/r/felddy/foundryvtt
License: MIT License
Error appears in logs related to unset CONTAINER_PATCHES variable when this is supposed to be optional. Does not prevent startup.
Steps to reproduce the behavior:
No errors logged for unused parameters.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
com.foundryvtt.version = "0.6.4"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-06-29 19:55:59+00:00"
org.opencontainers.image.licenses = "CC0-1.0"
org.opencontainers.image.revision = "61dd6a9b3a2394716bb7ac367f07f5e953f689c3"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.4"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
foundry | ./entrypoint.sh: line 107: CONTAINER_PATCHES: parameter not set
I suspect this is less bug and more user error. I'm setting up FoundryVTT through docker, and using apache to handle the reverse proxy. I can connect and download and access resources, but in the log, when I enter the map I get the following error:
The WebRTC server was requested to start, but Foundry Virtual Tabletop is not running in SSL mode which is required.
When I'd been trying to do this without docker, I had successfully gotten past this after getting a cert for the subdomain it's using through letsencrypt. The cert is still valid, and all I had to do in apache was repoint where the proxy needed to look at (from another physical IP to localhost).
I'm thinking there's either a way I need to be able to pass information about the subdomain's ssl cert to the container or force it to use ssl mode, but i'm not sure how to do it
Is there a way to incorporate FTP/SFTP/SAMBA/WEBDAV or any other protocol which would allow access to the app directory from outside the container to allow easier work with assets and worlds migrations for example ?
Hey Felddy.
I would like to brains storm with you something that I was thinking to add but I'm not sure if would make a lot of sense.
As we are using containers let's imagine that I have my 5gb assets folder or have a world world ready to play and would like to add to a clean server for any weird reason.
I was thinking a mechanism similar to what you do with foundry.zip now to incase some environment variables are passed with the URL of the location of the file it would fetch it and unzip on the proper directories o form the /data/Data.
This could also work for doing some git clones too so you don't need to go for the interface and select the mechanics and you can have a setup fully configured based on the environments variable and you could just "docker-compose up" or in may case "helm install foundry-vtt/" and couple seconds later everything is there.
What do you think about it?
Thanks.
When I set up my docker run command, I told it to use FOUNDRY_PUID and FOUNDRY_GUID as 1000, which is my personal user account. However, the web host that's handling proxy is running from a different user (normal linux www-data). Neither seems to be what the container is using as the mount point for the /data folder on the host system is shown as the following:
drwxr-xr-x 5 421 421 4096 Dec 1 20:30 foundryvtt
(yes, the user and group are showing as a right aligned '421' instead of normal left aligned alpha characters) I don't see anything like this in my console manager's user or group lists, but I'm sure it's something Docker related
While mildly annoying that I can't manipulate the directory without elevated permissions, I'm also thinking this could or could not have an issue with where I attempted to upload a map it uploads, but I can't seem to view it on the board (this could also be new user syndrome)
Hi, is there any way to automatically accept the license on startup? I feel like if I've already done it, I shouldn't have to do it again.
Mabye this is more of a foundry quirk, than something related to your container?
Crash on startup for latest container version.
Steps to reproduce the behavior:
The container starts up and runs.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
com.foundryvtt.version = "0.6.4"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-06-23 19:14:35+00:00"
org.opencontainers.image.licenses = "CC0-1.0"
org.opencontainers.image.revision = "dab35fcf04e63049d8777b2f3bedb10844c9e33c"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.4"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
foundry | Downloading Foundry release.
foundry | Connecting to foundryvtt.s3.amazonaws.com (52.218.213.10:443)
foundry | saving to 'foundryvtt-0.6.4.zip'
foundry | foundryvtt-0.6.4.zip 4% |* | 4342k 0:00:20 ETA
foundry | foundryvtt-0.6.4.zip 16% |***** | 14.9M 0:00:10 ETA
foundry | foundryvtt-0.6.4.zip 28% |********* | 25.6M 0:00:07 ETA
foundry | foundryvtt-0.6.4.zip 40% |************ | 36.4M 0:00:05 ETA
foundry | foundryvtt-0.6.4.zip 51% |**************** | 47.1M 0:00:04 ETA
foundry | foundryvtt-0.6.4.zip 63% |******************** | 57.8M 0:00:03 ETA
foundry | foundryvtt-0.6.4.zip 75% |************************ | 68.5M 0:00:02 ETA
foundry | foundryvtt-0.6.4.zip 87% |*************************** | 79.2M 0:00:01 ETA
foundry | foundryvtt-0.6.4.zip 98% |******************************* | 89.8M 0:00:00 ETA
foundry | foundryvtt-0.6.4.zip 100% |********************************| 90.8M 0:00:00 ETA
foundry | 'foundryvtt-0.6.4.zip' saved
foundry | Installing Foundry Virtual Tabletop 0.6.4
foundry | Switching uid:gid to 111:115 and restarting.
foundry | Starting felddy/foundryvtt container v0.6.4
foundry | Foundry Virtual Tabletop 0.6.4 is installed.
foundry | Generating options.json file.
foundry | Setting 'Admin Access Key'.
foundry | Starting Foundry Virtual Tabletop.
foundry | SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_homedir returned ENOENT (no such file or directory)
foundry | at _getEnvDataPath (/home/foundry/resources/app/main.js:128:22)
foundry | at getPaths (/home/foundry/resources/app/main.js:55:23)
foundry | at Object.<anonymous> (/home/foundry/resources/app/main.js:158:18)
foundry | at Module._compile (internal/modules/cjs/loader.js:1138:30)
foundry | at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
foundry | at Module.load (internal/modules/cjs/loader.js:986:32)
foundry | at Function.Module._load (internal/modules/cjs/loader.js:879:14)
foundry | at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
foundry | at internal/main/run_main_module.js:17:47
Determine what serviceConfig
option does, and support its configuration.
This is visible in 0.8.1
. It might have been in 0.8.0
.
Undocumented at time of issue creation.
This is an attempt to document the problem described in PR #146 by
I noticed while using the container in a docker-compose stack that if I do a stop then an up the container freezes while asking the user to overwrite the Foundry application files.
I am unable to reproduce it, but hope that I can get some log output from @dankreek demonstrating the behavior.
PR #146 should fix the issue as described, but the container should not be able to get into this state to begin with. If it detects an existing installation it should not try to unzip a new release. I'd like to track the root cause down.
Steps to reproduce the behavior:
up
the container using a composition.stop
the composition.up
the composition.up
.stop
.up
without reinstalling FoundryVTT.I am seeing the expected behavior. See logs below.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:release
Paste the results here:
com.foundryvtt.version = "0.7.9"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-12-19T18:22:45Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "d7bbea8063e5cbf8cc93ef114aca843be45d299d"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.9"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
❱ docker-compose -f docker-compose-mine.yml up
Creating network "foundryvtt-docker_default" with the default driver
Creating foundryvtt-docker_foundry_1 ... done
Attaching to foundryvtt-docker_foundry_1
foundry_1 | Entrypoint | 2021-02-11 15:49:00 | [debug] Timezone set to: US/Eastern
foundry_1 | Entrypoint | 2021-02-11 15:49:00 | [info] Starting felddy/foundryvtt container v0.7.9
foundry_1 | Entrypoint | 2021-02-11 15:49:00 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.
foundry_1 | Entrypoint | 2021-02-11 15:49:00 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1 | Entrypoint | 2021-02-11 15:49:01 | [info] No Foundry Virtual Tabletop installation detected.
foundry_1 | Entrypoint | 2021-02-11 15:49:01 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundry_1 | Authenticate | 2021-02-11 15:49:01 | [debug] Saving cookies to: cookiejar.json
foundry_1 | Authenticate | 2021-02-11 15:49:01 | [info] Requesting CSRF tokens from https://foundryvtt.com
foundry_1 | Authenticate | 2021-02-11 15:49:01 | [debug] Fetching: https://foundryvtt.com
foundry_1 | Authenticate | 2021-02-11 15:49:02 | [info] Logging in as: xxx
foundry_1 | Authenticate | 2021-02-11 15:49:02 | [debug] Fetching: https://foundryvtt.com/auth/login/
foundry_1 | Authenticate | 2021-02-11 15:49:02 | [debug] Community URL: /community/xxx
foundry_1 | Authenticate | 2021-02-11 15:49:02 | [info] Successfully logged in as: xxx
foundry_1 | Entrypoint | 2021-02-11 15:49:02 | [info] Using authenticated credentials to download release.
foundry_1 | ReleaseURL | 2021-02-11 15:49:02 | [debug] Loading cookies from: cookiejar.json
foundry_1 | ReleaseURL | 2021-02-11 15:49:02 | [info] Fetching S3 pre-signed release URL for 0.7.9...
foundry_1 | ReleaseURL | 2021-02-11 15:49:02 | [debug] Fetching: https://foundryvtt.com/releases/download?version=0.7.9&platform=linux
foundry_1 | ReleaseURL | 2021-02-11 15:49:03 | [debug] S3 presigned URL: ...
foundry_1 | Entrypoint | 2021-02-11 15:49:03 | [info] Using CONTAINER_CACHE: /data/container_cache
foundry_1 | Entrypoint | 2021-02-11 15:49:03 | [info] Downloading Foundry Virtual Tabletop release.
foundry_1 | % Total % Received % Xferd Average Speed Time Time Time Current
foundry_1 | Dload Upload Total Spent Left Speed
foundry_1 |
foundry_1 | 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
foundry_1 | 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
foundry_1 | Entrypoint | 2021-02-11 15:49:03 | [info] Installing Foundry Virtual Tabletop 0.7.9
foundry_1 | Entrypoint | 2021-02-11 15:49:06 | [debug] Installation completed.
foundry_1 | Entrypoint | 2021-02-11 15:49:06 | [info] Preserving release archive file in cache.
foundry_1 | Entrypoint | 2021-02-11 15:49:06 | [debug] Editing server update error message.
foundry_1 | Entrypoint | 2021-02-11 15:49:06 | [info] Not modifying existing installation license key.
foundry_1 | Entrypoint | 2021-02-11 15:49:06 | [info] Setting data directory permissions.
foundry_1 | Entrypoint | 2021-02-11 15:49:23 | [debug] Completed setting directory permissions.
foundry_1 | Entrypoint | 2021-02-11 15:49:23 | [info] Starting launcher with uid:gid as 501:20.
foundry_1 | Launcher | 2021-02-11 15:49:23 | [debug] Ensuring /data/Config directory exists.
foundry_1 | Launcher | 2021-02-11 15:49:23 | [info] Generating options.json file.
foundry_1 | Launcher | 2021-02-11 15:49:23 | [info] Setting 'Admin Access Key'.
foundry_1 | Launcher | 2021-02-11 15:49:23 | [info] Starting Foundry Virtual Tabletop.
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] Foundry Virtual Tabletop - Version 0.7.9
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] Running on Node.js - Version 12.20.0
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] Loading data from user directory - /data
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] Application Options:
foundry_1 | {
...
foundry_1 | }
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] License verification succeeded
foundry_1 | FoundryVTT | 2021-02-11 15:49:25 | [info] Server started and listening on port 30000
docker-compose -f docker-compose-mine.yml stop
foundryvtt-docker_foundry_1 exited with code 143
❱ docker-compose -f docker-compose-mine.yml up
Starting foundryvtt-docker_foundry_1 ... done
Attaching to foundryvtt-docker_foundry_1
foundry_1 | Entrypoint | 2021-02-11 15:52:08 | [debug] Timezone set to: US/Eastern
foundry_1 | Entrypoint | 2021-02-11 15:52:08 | [info] Starting felddy/foundryvtt container v0.7.9
foundry_1 | Entrypoint | 2021-02-11 15:52:08 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.
foundry_1 | Entrypoint | 2021-02-11 15:52:08 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1 | Entrypoint | 2021-02-11 15:52:09 | [info] Foundry Virtual Tabletop 0.7.9 is installed.
foundry_1 | Entrypoint | 2021-02-11 15:52:09 | [info] Not modifying existing installation license key.
foundry_1 | Entrypoint | 2021-02-11 15:52:09 | [info] Setting data directory permissions.
foundry_1 | Entrypoint | 2021-02-11 15:52:27 | [debug] Completed setting directory permissions.
foundry_1 | Entrypoint | 2021-02-11 15:52:27 | [info] Starting launcher with uid:gid as 501:20.
foundry_1 | Launcher | 2021-02-11 15:52:27 | [debug] Ensuring /data/Config directory exists.
foundry_1 | Launcher | 2021-02-11 15:52:27 | [info] Generating options.json file.
foundry_1 | Launcher | 2021-02-11 15:52:27 | [info] Setting 'Admin Access Key'.
foundry_1 | Launcher | 2021-02-11 15:52:27 | [info] Starting Foundry Virtual Tabletop.
foundry_1 | FoundryVTT | 2021-02-11 15:52:28 | [info] Foundry Virtual Tabletop - Version 0.7.9
foundry_1 | FoundryVTT | 2021-02-11 15:52:28 | [info] Running on Node.js - Version 12.20.0
foundry_1 | FoundryVTT | 2021-02-11 15:52:28 | [info] Loading data from user directory - /data
foundry_1 | FoundryVTT | 2021-02-11 15:52:28 | [info] Application Options:
foundry_1 | {
...
foundry_1 | }
foundry_1 | FoundryVTT | 2021-02-11 15:52:28 | [info] License verification succeeded
foundry_1 | FoundryVTT | 2021-02-11 15:52:29 | [info] Server started and listening on port 30000
Current behavior is that use FOUNDRY_USERNAME
/FOUNDRY_PASSWORD
(and FOUNDRY_VERSION
if necessary) to fetch release URL even if you already set FOUNDRY_RELEASE_URL
env var.
foundryvtt-docker/src/entrypoint.sh
Lines 69 to 79 in 70ead2b
Requested feature is that always prefer FOUNDRY_RELEASE_URL
if set, if it's invalid, use USERNAME/PASSWORD/VERSION to fetch S3 release URL, i.e.
if [ "${FOUNDRY_RELEASE_URL:-}" ]; then
log "Using FOUNDRY_RELEASE_URL to download release."
s3_url="${FOUNDRY_RELEASE_URL}"
elif [[ "${FOUNDRY_USERNAME:-}" && "${FOUNDRY_PASSWORD:-}" ]]; then
log "Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate."
# CONTAINER_VERBOSE default value should not be quoted.
# shellcheck disable=SC2086
./authenticate.js ${CONTAINER_VERBOSE+--log-level=debug} "${FOUNDRY_USERNAME}" "${FOUNDRY_PASSWORD}" "${cookiejar_file}"
# shellcheck disable=SC2086
s3_url=$(./get_release_url.js ${CONTAINER_VERBOSE+--log-level=debug} "${cookiejar_file}" "${FOUNDRY_VERSION}")
fi
FOUNDRY_RELEASE_URL
is a more detailed option, should be at higher priority than USERNAME/PASSWORD and especially because it explicitly specifies version other than the default VERSION argument or env var.
docker run -e FOUNDRY_RELEASE_URL='https://dl/linux/fvtt.zip' -e FOUNDRY_USERNAME='myAccount' -e FOUNDRY_PASSWORD='myPassword' felddy/foundryvtt
It should use https://dl/linux/fvtt.zip
to download instead of fetching release URL by USERNAME/ACCOUNT.
Foundry VTT Docker behavior related.
Mark --
First off; thank you for creating and maintaining this image.
I just updated to 0.7.5 and on my docker-compose up
, the server hangs and I see:
foundry | FoundryVTT | 2020-10-22 11:18:37 | [info] License verification succeeded
foundry | FoundryVTT | 2020-10-22 11:18:37 | [info] Server started and listening on port 30000
foundry | FoundryVTT | 2020-10-22 11:18:42 | [error] Unable to update lock within the stale threshold
foundry | Error: Unable to update lock within the stale threshold
foundry | at /home/foundry/resources/app/node_modules/proper-lockfile/lib/lockfile.js:136:25
foundry | at /home/foundry/resources/app/node_modules/proper-lockfile/node_modules/graceful-fs/polyfills.js:285:20
foundry | at FSReqCallback.oncomplete (fs.js:169:5)
Of note -- my Foundry data is stored on a network mounted drive, and has worked properly for a while now, but it seems like it may be relevant here. Help?
I installed using FOUNDRY_RELEASE_URL
which worked the first time, but when I restarted the container it tried to download again but the URL was no longer valid. I have a volume mount for /data
, but no other volume mount, so it isn't surprising that the actual install wasn't retained.
FOUNDRY_RELEASE_URL
and /data
mounted.No Foundry Virtual Tabletop installation detected.
and tries to download/install again.The download and install are saved to a volume so I don't have to re-download and re-install every run.
This may just be a documentation issue. Should I be mounting another volume besides /data
?
adding the -xdev
flag to the find command to skip setting permissions on a mounted point
Whenever I create a container with the image the find command in entrypoint.sh
user for setting permissions will crawl my nfs mounted points that I use for assets, destroying all of the permissions on the drive along with hanging for a very long time while it does so. Some people like me map assets on a network drive and mount it at the root folder so it is accessible to all worlds within a foundry instance. In my case in /data/assets
. This is not desirable.
This is the command it runs :
foundryvtt-docker/src/entrypoint.sh
Line 212 in 8c0e0dc
This is the proposed change :
find /data -regex "${CONTAINER_PRESERVE_OWNER:-}" -xdev -prune -o -exec chown "${FOUNDRY_UID:-foundry}:${FOUNDRY_GID:-foundry}" {} +
I believe the most common usecase for mounting a folder inside the /data folder is to mount network storage with assets.
I believe this will not impact regular users and prevent having to maintain a patch for the issue.
Thanks for considering it
I would like a flag that would have the startup script skip the chmod of the data directory on startup
I mount the data directories from NFS, and I've already set the proper permissions on all files. With hundreds upon hundreds of shared files, it takes about three to four minutes on my saves
On environments where you know the uid/gid of the files ahead of time, you could opt to skip this stick
Makes restarting containers, or setting up new containers with shared data much faster, and for minimal effort
Currently, in entrypoint.sh
when download FoundryVTT ZIP file, CURL doesn't follow 302 Redirect, causing failed download if that URL responses 302.
foundryvtt-docker/src/entrypoint.sh
Lines 92 to 98 in ea65443
I'd say it's better to add -L
/--location
option to respect 302 Redirect.
Following 302 Redirect will make the download process more "compatible" with provided other URLs than the direct URL.
Corresponding FOUNDRY_RELEASE_URL
returns 301 Moved or 302 Redirect.
docker run -e FOUNDRY_RELEASE_URL='https://dl/linux/fvtt.zip' felddy/foundryvtt-docker
When downloading, CURL uses --location
to respect that 301/302 status code and go to Location to get the zip.
Foundry VTT Docker related.
I'd like to supply my own dns server with the container using the --dns attribute. Yet this is not correctly picked up and inserted into the /etc/resolv.conf. This makes it impossible for the container to run in bridge networking mode
Steps to reproduce the behavior:
I'm expecting the DNS to be populated into the /etc/resolv.conf. I don't know how ever why it isn't
This works fine for all my other containers I'm running.
I use docker-compose
version: "3.3"
secrets:
config_json:
file: /share/Container/foundryvtt-secrets.json
services:
foundry:
image: felddy/foundryvtt:0.7.8
hostname: foundryvtt
mac_address: 24:5E:BE:00:00:F6
dns:
- 192.168.1.2
- 8.8.8.8
- 8.8.4.4
networks:
qnet-static-eth0-79e6cc:
ipv4_address: 192.168.1.246
volumes:
- type: bind
source: /share/Container/foundryvtt
target: /data
environment:
- FOUNDRY_LICENSE_KEY=*
- CONTAINER_CACHE=/data/container_cache
- CONTAINER_PATCHES=/data/container_patches
secrets:
- source: config_json
target: config.json
networks:
qnet-static-eth0-79e6cc:
external: true
Paste the results here:
Entrypoint | 2020-12-25 09:30:07 | [info] Starting felddy/foundryvtt container v0.7.8
Entrypoint | 2020-12-25 09:30:07 | [info] Reading configured secrets from: /run/secrets/config.json
Entrypoint | 2020-12-25 09:30:09 | [info] No Foundry Virtual Tabletop installation detected.
Entrypoint | 2020-12-25 09:30:09 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
Authenticate | 2020-12-25 09:30:14 | [info] Requesting CSRF tokens from https://foundryvtt.com
Authenticate | 2020-12-25 09:30:19 | [error] Unable to authenticate: request to https://foundryvtt.com/ failed, reason: getaddrinfo EAI_AGAIN foundryvtt.com
The /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0
I can load foundry and use it just fine internally at http://localhost:30000/ , but when I try to connect to my internet facing hostname with letsencrypt cert all configured, using the Apache2 SSL Proxy config from this page, the setup page loads, but I can't login and keep getting this error in the browser console:
Firefox can’t establish a connection to the server at wss://foundry.mydomain.com/socket.io/?session=<sessionid>&transport=websocket.
(note the extra 's' in wss above)
My VirtualHost has this line (from the page above):
ProxyPass "/socket.io/" "ws*//<my foundry internal ip>:30000/socket.io/"
Is it possible that there's a configuration in your container that is asking for a connection to wss:// instead of ws://? I'm at a loss and don't know how to proceed.
Apache Log, fwiw, says:
[proxy:error] [pid 29863] (111)Connection refused: AH00957: HTTP: attempt to connect to <my foundry internal ip>:30000 (<internal ip again>) failed
Possibly I don't understand how the image works, but my assumption was that today (Oct 3, 2020), using :beta
would pull version 0.7.3
Steps to reproduce the behavior:
felddy/foundryvtt-docker:beta
Foundry version 0.7.3 is installed in the container
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
Hey Felddy
I'm migrating my helm-chart to your container and I have found a bug :)
My password contains $a
.
As you know the $a
on shell when enclosed by double-quotes are executed trying to retrieve the value of a, and the $
ended stripped.
I have check the download_release.py
sending my execution with single-quotes and it works, so that part of the code is 100%.
I also checked the the Dockerfile and it looks 100%
https://github.com/felddy/foundryvtt-docker/blob/develop/Dockerfile#L21
To fix it I just had to enclose the password and username with single-quotes on the commands.
Like so:
docker-compose build \
--build-arg USERNAME='your_username' \
--build-arg PASSWORD='your_password'
I'm doing a PR to fix this as users less skilled in docker may face similar issues.
2020-05-25 09:10:46,845 CRITICAL Unable to log in as <username>, verify your credentials.
foundryvtt.com went down for a few minutes earlier today, at the same time that I was trying to bring my container up. The container failed to authenticate and gave up.
The release zip had already been downloaded from a previous run, and was in the cache, so it could have just carried on with the cached one.
I was using release v0.7.5 happily using Foundry VTT username and password. It fetched license as expected. But I decided to upgrade to the new v0.7.7 using docker-compose pull
as stated in README.md file. I use the same data
volume. When I try to use my deployment again, logs say (my license is valid):
[error] License verification failed. Please confirm your Foundry Virtual Tabletop software license
I verified that the data/Config/license.json
contains valid information, fetched again after last run.
What I am doing wrong? Do I need to create data
volume again? I would like to maintain my worlds, plugins and configuration.
Is it possible to set the data folder to rw permission? When I up my image, the permission of the data folder change to docker user, and it's not possible anymore to change unless I do it in Foundry.
The license key retrieval retrieves the text contents of a CSS selector
const license_with_dashes = $("pre.license-key code").text();
If there are multiple pre
s, it concatenates the contents of each and writes that into the license file, resulting in an invalid license
Steps to reproduce the behavior:
Ability to specify the license key as an ARG or in the secret. I am currently looking at the code to make that happen and provide a PR if sucessful, but I have to admit that Docker is not my strong suit
There is a hotfix for 0.7.8 on the discord server. Could this be added to the docker version of 0.7.8 please?
https://discord.com/channels/170995199584108546/784244473261588480/784490927212855317
Node.js version 14 or newer is now required for FoundryVTT.
See:
https://foundryvtt.com/article/hosting/#install
https://gitlab.com/foundrynet/foundryvtt/-/issues/3545
Reported by: @shirkie
If FOUNDRY_USERNAME
is set to foobar
it is possible for FoundryVTT can respond with:
Successfully logged in as: Foobar
(note the case change)
We use the reply username since some users set FOUNDRY_USERNAME
to their email address.
When the LICENSE_URL
is constructed, it is invalid with the capitalized username.
The solution is to lowercase the returned username before it is used in the URL.
Steps to reproduce the behavior:
Paste the results here:
(simulated output)
foundry_1 | Starting felddy/foundryvtt container v0.6.1
foundry_1 | No Foundry Virtual Tabletop installation detected.
foundry_1 | Installing Foundry Virtual Tabletop 0.6.1
foundry_1 | [2020-06-05 14:22:42.739 +0000] INFO : Requesting CSRF tokens from https://foundryvtt.com
foundry_1 | [2020-06-05 14:22:43.351 +0000] INFO : Logging in as: foobar
foundry_1 | [2020-06-05 14:22:44.080 +0000] INFO : Successfully logged in as: Foobar
foundry_1 | [2020-06-05 14:22:44.080 +0000] INFO : Fetching license.
(node:7) UnhandledPromiseRejectionWarning: Error: Unexpected response Not Found
...
Running using docker-compose, setting port to something like 30002 in the yaml file and also changing it in options.json file, when restarting the image, it resets back to port 30000. How would I run an instance using a different port?
foundry:
container_name: fvtt
image: felddy/foundryvtt:release
restart: "unless-stopped"
volumes:
- '/data/docker/foundryvtt:/data'
environment:
- FOUNDRY_PASSWORD=password
- FOUNDRY_USERNAME=user
- FOUNDRY_ADMIN_KEY=anotherpassword
ports:
- "30002:30002/tcp"
network_mode: host
The health check provided by check_health.sh
does not provide the correct container status when the container is running using https (not behind nginx or other such server).
Https means setting the paths for both sslKey
and sslCert
and using the inbuilt
ssl server.
Steps to reproduce the behavior:
Start container using a docker-compose.yml specifying the environment variables for sslKey
and sslCert
Inspect container using docker ps <container-id>
or similar command interface such as portainer
See the container status is unhealthy
Expect to see the container status as healthy
especially when it is idle.
You can observe the container is actually healthy by getting a shell into the container and running curl -k --cookie-jar healthcheck-cookiejar.txt --cookie healthcheck-cookiejar.txt --fail https://localhost:30000/api/status
which on the image tag felddy/foundryvtt-docker:0.7.5
release produces this result {"version":"0.7.5"}
.
The -k
argument may not be the best to use from a security standpoint as you might be using a self signed certificate, but this can be worked around by passing the sslCert
and sslKey
variables into the check_health.sh
script if correct https validation is needed to be performed.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
com.docker.compose.config-hash = "8bc8ddd3796576d04e2f1092fbc0dcd2123a3a2316f481fa0f0c94341cefc1e4"
com.docker.compose.container-number = "1"
com.docker.compose.oneoff = "False"
com.docker.compose.project = "foundryvtt"
com.docker.compose.project.config_files = "docker-compose.yml"
com.docker.compose.project.working_dir = "/home/christian/Docker/foundryvtt"
com.docker.compose.service = "foundryvtt"
com.docker.compose.version = "1.27.4"
com.foundryvtt.version = "0.7.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.vendor = "Geekpad"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
This shows the container is idle and currently accepting connections
FoundryVTT | 2020-10-25 16:48:19 | [info] License verification succeeded
FoundryVTT | 2020-10-25 16:48:20 | [info] Server started and listening on port 30000
FoundryVTT | 2020-10-25 16:48:30 | [info] Created client session 68xp6fdwr2dmhslhn4xz7htl
FoundryVTT | 2020-10-25 16:48:31 | [info] No core software update is currently available.
FoundryVTT | 2020-10-25 16:53:14 | [info] Created client session w2gv92i94osfp55zdc6gglcm
Add missing configuration for AWS_CONFIG to expand the usage to AWS S3.
When the entrypoint.sh
drops privileges via su-exec
, and calls itself, it loses the ability to read from /run/secrets/config.json
which is mode 0600 and owned by root:root. This causes a failure of the unprivileged user to read the secrets file, resulting in unpopulated variables, and unconfigured options (eg - admin access key).
docker-compose up
Data from secrets should be correctly populated.
As an aside, I'd strongly suggest splitting the entrypoint.sh
out into two files - one to do the bootstrapping with elevated privileges, and one that's executed with reduced privs that actually runs the application. This will make it vastly easier to understand what should be done and what privs are expected, at each stage.
I can see a few ways of solving this problem (roughly in order of preference):
export
the variables that hold the associated values, so that the sub-process has access to them without needing access to the secrets fileVersion info (release tag):
com.foundryvtt.version = "0.6.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-07-26 20:39:57+00:00"
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "dad0abfe061e9dbae536bf986cd1533a8c2f97e5"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "Foundry Virtual Tabletop"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.6.5"
Log output illustrating problems:
foundry_1 | Entrypoint | 2020-08-02 07:01:24 | [info] Starting felddy/foundryvtt container v0.6.5
foundry_1 | Entrypoint | 2020-08-02 07:01:24 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1 | Entrypoint | 2020-08-02 07:01:25 | [info] No Foundry Virtual Tabletop installation detected.
foundry_1 | Entrypoint | 2020-08-02 07:01:25 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundry_1 | Authenticate | 2020-08-02 07:01:25 | [debug] Saving cookies to: cookiejar.json
foundry_1 | Authenticate | 2020-08-02 07:01:25 | [info] Requesting CSRF tokens from https://foundryvtt.com
foundry_1 | Authenticate | 2020-08-02 07:01:25 | [debug] Fetching: https://foundryvtt.com
foundry_1 | Authenticate | 2020-08-02 07:01:26 | [info] Logging in as: <redacted>
foundry_1 | Authenticate | 2020-08-02 07:01:26 | [debug] Fetching: https://foundryvtt.com/auth/login/
foundry_1 | Authenticate | 2020-08-02 07:01:26 | [debug] Community URL: /community/<redacted>
foundry_1 | Authenticate | 2020-08-02 07:01:26 | [info] Successfully logged in as: <redacted>
foundry_1 | ReleaseURL | 2020-08-02 07:01:26 | [debug] Loading cookies from: cookiejar.json
foundry_1 | ReleaseURL | 2020-08-02 07:01:26 | [info] Fetching S3 pre-signed release URL for 0.6.5...
foundry_1 | ReleaseURL | 2020-08-02 07:01:26 | [debug] Fetching: https://foundryvtt.com/releases/download?version=0.6.5&platform=linux
foundry_1 | ReleaseURL | 2020-08-02 07:01:26 | [debug] S3 presigned URL: https://foundryvtt.s3.amazonaws.com/releases/0.6.5/foundryvtt-0.6.5.zip?<redacted>
foundry_1 | Entrypoint | 2020-08-02 07:01:26 | [info] Using CONTAINER_CACHE: /data/container_cache
foundry_1 | Entrypoint | 2020-08-02 07:01:26 | [info] Downloading Foundry Virtual Tabletop release.
foundry_1 | % Total % Received % Xferd Average Speed Time Time Time Current
foundry_1 | Dload Upload Total Spent Left Speed
foundry_1 |
foundry_1 | 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
foundry_1 | 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
foundry_1 | Entrypoint | 2020-08-02 07:01:27 | [info] Installing Foundry Virtual Tabletop 0.6.5
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Preserving release archive file in cache.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Not modifying existing installation license key.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Setting data directory permissions.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Switching uid:gid to foundry:foundry and restarting.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Starting felddy/foundryvtt container v0.6.5
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Reading configured secrets from: /run/secrets/config.json
foundry_1 | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1 | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1 | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1 | jq: error: Could not open file /run/secrets/config.json: Permission denied
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Foundry Virtual Tabletop 0.6.5 is installed.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Not modifying existing installation license key.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Generating options.json file.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [warn] Warning: No 'Admin Access Key' has been configured.
foundry_1 | Entrypoint | 2020-08-02 07:01:29 | [info] Starting Foundry Virtual Tabletop.
foundry_1 | FoundryVTT | 2020-08-02 07:01:30 | [info] Foundry Virtual Tabletop - Version 0.6.5
foundry_1 | FoundryVTT | 2020-08-02 07:01:30 | [info] Running on Node.js - Version 12.18.2
foundry_1 | FoundryVTT | 2020-08-02 07:01:30 | [info] Loading data from user directory - /data
foundry_1 | FoundryVTT | 2020-08-02 07:01:30 | [info] Application Options:
foundry_1 | {
foundry_1 | "port": 30000,
foundry_1 | "upnp": false,
foundry_1 | "fullscreen": false,
foundry_1 | "hostname": "<redacted>",
foundry_1 | "routePrefix": null,
foundry_1 | "sslCert": null,
foundry_1 | "sslKey": null,
foundry_1 | "awsConfig": null,
foundry_1 | "dataPath": "/data",
foundry_1 | "proxySSL": false,
foundry_1 | "proxyPort": null,
foundry_1 | "updateChannel": "release",
foundry_1 | "noUpdate": true,
foundry_1 | "world": null,
foundry_1 | "isElectron": false,
foundry_1 | "isNode": true,
foundry_1 | "isSSL": false
foundry_1 | }
foundry_1 | FoundryVTT | 2020-08-02 07:01:31 | [warn] Software license requires signature.
foundry_1 | FoundryVTT | 2020-08-02 07:01:31 | [info] Server started and listening on port 30000
Per the optimization recommendations at https://prezi.com/view/Wpq1WQv92LC1KNwwAEyG/, put together by Anathema, this can force Foundry to use Hardware acceleration when it might otherwise be attempting to use software rendering, thus improving performance. This would be optional, and it could also cause problems with unsupported graphics cards.
Was double-checking my setup and could not verify that this was being performed in the container.
Set the FOUNDRY_IGNORE_GPU_BLACKLIST env variable to true and it will add the --ignore-gpu-blacklist flag to the command line when launching Foundry.
Recommended best practice for troubleshooting poor performance by the community lead for Foundry?
Hi Felddy,
I saw that you have changed the behaviour of the image pulling for the .js alternative and with that dropped the capability of a fetch-install during the build using the old command.
docker-compose build \
--build-arg USERNAME='user' \
--build-arg PASSWORD='mYPa$$'
Do you plan to re-add it in any other way?
I'm checking too ensure that the K8S chart reflects how it works and I would like to avoid asking for the users to provide passwords on the vales.yaml or parameter and deliver it as a environment variable plain text to the container during it's execution, that it's not safe.
Hi. When I upload modules directly to the Data folder on our Synology server, and then restart the synology, the new modules are not seen by Foundry. If I open a browser in Foundry and go to modules folder, the new modules are seen but they do not show up in the setup modules list.
Please advise what to do, I don't know if this is a bug or not.
After entering the admin password, the website crashed with a cross-origin error.
Steps to reproduce the behavior:
Update to the current release version.
Try to activate VTT using the correct admin password.
Entering the correct credentials should lead me to my vtt setup.
The linux/386
platform build is breaking. This was caused by nodejs/docker-node#1344
The platform was disabled as a workaround in 2d6e989
Worked up to version: 0.7.3
Stopped working in version: 0.7.4
Steps to reproduce the behavior:
Expected that 386 architecture would be supported.
Please run this command:
#20 [linux/386 optional-release-stage 1/5] FROM docker.io/library/node:12-al...
#20 resolve docker.io/library/node:12-alpine 0.4s done
#20 ERROR: no match for platform in manifest sha256:53bbb1eeb8bc916ee27f9e01c542788699121bd7b5a9d9f39eaff64c2fcd0412: not found
I use a raspi4 for my Foundry hosting, I have no problems using felddy/foundryvtt:0.7.9
(I have tried to recrate it after the present bug and had no problem.
But trying a docker-compose up --build
of the following configuration I get an Illegal instruction (core dumped)
foundryvtt85:
image: felddy/foundryvtt:beta
hostname: vehrka_foundry_85_cheraserver
init: true
restart: "unless-stopped"
volumes:
- type: bind
source: /home/perico/share/foundrydata_8_5
target: /data
- type: bind
source: /etc/letsencrypt
target: /etc/foundryssl
environment:
- CONTAINER_CACHE=/data/container_cache
- CONTAINER_PRESERVE_CONFIG=true
- FOUNDRY_UID=1001
ports:
- target: "30000"
published: "30000"
protocol: tcp
secrets:
- source: config_json
target: config.json
Steps to reproduce the behavior:
docker-compose up --build foundryvtt85
for the above configurationExpected to work as the 0.7.9 version does.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:beta
Paste the results here:
com.foundryvtt.version = "0.8.5"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2021-05-21T19:43:06Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "6b2080cb273fabff368ac7c862b68cabbc64aea9"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.8.5"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
foundryvtt85_1 | Entrypoint | 7923-11-24 00:40:56 | [debug] Timezone set to: UTC
foundryvtt85_1 | Entrypoint | 7923-11-26 17:32:08 | [info] Starting felddy/foundryvtt container v0.8.5
foundryvtt85_1 | Entrypoint | 7923-12-08 13:58:48 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.
foundryvtt85_1 | Entrypoint | 7923-09-15 17:15:04 | [info] Reading configured secrets from: /run/secrets/config.json
foundryvtt85_1 | Entrypoint | 7923-10-24 11:57:12 | [info] No Foundry Virtual Tabletop installation detected.
foundryvtt85_1 | Entrypoint | 7923-11-09 01:08:40 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
foundryvtt85_1 |
foundryvtt85_1 |
foundryvtt85_1 | #
foundryvtt85_1 | # Fatal error in , line 0
foundryvtt85_1 | # unreachable code
foundryvtt85_1 | #
foundryvtt85_1 | #
foundryvtt85_1 | #
foundryvtt85_1 | #FailureMessage Object: 0xbef7750c
foundryvtt85_1 | Illegal instruction (core dumped)
Enable some method of running container patch scripts for containers built with credentials.
I prefer to build the containers with foundry installed using my credentials but also enjoy the convenience of the patch scripts. I personally patched entrypoint.sh
to run the patch scripts every launch not just when foundry is being installed but figured there might be a better mechanism for this. Potentially running them during container build. Figured I would propose the option.
The best implementation of this I see is adding patch scripts as a build ARG
just like the credentials are. This would enable the scripts to be run just once while also providing nearly the same experience as passing the urls as environment variables.
It is a simple extension of a preexisting feature. Should add little to no maintenance cost on the project. I would be willing to give it a go for my own personal usage if anyone is interested here.
When I try to make configuration changes on the setup page (default world, admin password, etc) they don't seem to save. The container restarts but nothing changes once it's back up.
Steps to reproduce the behavior:
For the changed values to stay changed
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
com.foundryvtt.version = "0.8.6"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2021-05-31T15:02:59Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "44f414116ddaf1fb9ba2d8c9f6ebf1bb79fa34a0"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.8.6"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
I don't see any log output that would relate to this. debug.log
doesn't seem to contain anything related to this issue and error.log
only seems to have errors from some of my modules.
Requested by @kakaroto
Allow users to provide a pre-signed S3 URL as the mechanism to download the foundry release. These URLs may be generated from the user's profile page by clicking on the 🔗 icon next to the distribution.
Also update the documentation to note the HISTCONTROL
options available in bash
. Especially the prepended space to prevent saving a command to history.
See: https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html
OPSEC. Users may be wary or providing credentials to a container. Not all users have the ability to do a code review of project and trust the code is not harvesting their credentials. (It's not: ✋)
Providing the URL will allow users to sleep that much easier, and we all need that right now.
docker run \
--env FOUNDRY_RELEASE_URL='https://foundryvtt.s3.amazonaws.com/releases/0.6.2/foundryvtt-0.6.2.zip?AWSAccessKeyId=AKIAISZIIE42YLQZKLEQ&Signature=ctAA11fsXga%2FJUZ%2BblqKl3UJBCQ%3D&Expires=1591839231' \
--publish 30000:30000/tcp \
--volume /data:<your_data_dir> \
felddy/foundryvtt:latest
It will make users happier. And we like happy users.
Support using an email address as the FOUNDRY_USERNAME
.
Reported by: @Corvimae
It is possible to log in to foundryvtt.com using your email address. But when the download_release.js
helper util goes to fetch the license key, it will error out as it is trying to build a path with the username.
We could document that FOUNDRY_USERNAME
is not supposed to be an email address but user's don't read the docs, and it will be simpler in the long run to allow this to happen.
[email protected]
FOUNDRY_PASSWORD=yourmom
Make the user's lives easier. Things are hard enough nowadays.
Add support for a :release
tag that will point to the latest version from the Foundry "release" channel.
The release tag will be added to any GitHub published release that does not have the "pre-release" checkbox checked. Beta and alpha channel versions will continue to be published with the :latest
tag.
Not all users live on the bleeding edge. In fact, most users probably want the stable builds offered from the "release" channel. This will allow them to only receive these images.
docker run \
--env FOUNDRY_USERNAME='<your_username>' \
--env FOUNDRY_PASSWORD='<your_password>' \
--publish 30000:30000/tcp \
--volume /data:<your_data_dir> \
felddy/foundryvtt:release
It was requested by Tatonker on the Foundry discord. The users are always right... (usually)
Hey there. I'm trying to make foundryvtt run in my docker environment with nginx-proxy or traefik as reverse proxy (I've tried on two different servers), but it seems that I'm unable to get a valid ssl certificate.
Here are the error messages from both proxies:
Traefik
traefik | time="2020-11-27T09:40:39+01:00" level=error msg="Unable to obtain ACME certificate for domains \"sub.domain.tld\": unable to generate a certificate for the domains [sub.domain.tld]: error: one or more domains had a problem:\n[sub.domain.tld] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: The key authorization file from the server did not match this challenge \"4mkuOAtxpL7zv4TxQbdpj1oSbybHxb72M546moVM0bI.xIYdb4NK6tj3L953MqLSs6i7yY1p0v43kP5ZBrOOlHU\" != \"error_kas_28\", url: \n" rule="Host(`sub.domain.tld`)" providerName=http.acme routerName=foundryvtt-secure@docker
nginx-proxy
nginx-proxy | 2020/11/27 15:41:34 [warn] 44#44: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: "/etc/nginx/certs/sub.domain.tld.crt"
nginx-proxy | 2020/11/27 15:41:35 [error] 44#44: *4266 no live upstreams while connecting to upstream, client: 149.224.201.106, server: sub.domain.tld, request: "GET / HTTP/2.0", upstream: "http://sub.domain.tld/", host: "sub.domain.tld"
Here is my docker-compose file:
foundry:
image: felddy/foundryvtt:release
container_name: foundryvtt
init: true
restart: "unless-stopped"
volumes:
- foundry_data:/data
environment:
- FOUNDRY_HOSTNAME=sub.domain.tld
- FOUNDRY_PROXY_SSL=true
- TIMEZONE=Europe/Berlin
ports:
- "30000:30000"
secrets:
- source: config_json
target: config.json
labels:
- "traefik.enable=true"
- "traefik.http.routers.foundryvtt.entrypoints=http"
- "traefik.http.routers.foundryvtt.rule=Host(`sub.domain.tld`)"
- "traefik.http.middlewares.foundryvtt-https-redirect.redirectscheme.scheme=https"
- "traefik.http.routers.foundryvtt.middlewares=foundryvtt-https-redirect"
- "traefik.http.routers.foundryvtt-secure.entrypoints=https"
- "traefik.http.routers.foundryvtt-secure.rule=Host(`sub.domain.tld`)"
- "traefik.http.routers.foundryvtt-secure.tls=true"
- "traefik.http.routers.foundryvtt-secure.tls.certresolver=http"
- "traefik.http.routers.foundryvtt-secure.service=foundryvtt"
- "traefik.http.services.foundryvtt.loadbalancer.server.port=30000"
- "traefik.docker.network=web"
For nginx-proxy erase everything under label
and insert under environments
- VIRTUAL_HOST=sub.domain.tld
- LETSENCRYPT_HOST=sub.domain.tld
- [email protected]
- VIRTUAL_PORT=30000
I'm honest. I don't know what the problem is. For me, it seems that there is something with the container, since every other container on both server are running without any problems.
Maybe someone can point me in the right direction.
Thanks for your help in advance.
Hi,
Not sure if this is a foundry issue or a docker image issue, so I figured I'd ask.
I've configured the image on my remote server as well as nginx, and when I connect I get redirected to the license page as expected. But there's no text on the page, and so no way to proceed. Did I do something wrong in the setup?
My launch command is:
sudo podman run \
--env FOUNDRY_USERNAME='TTIO' \
--env FOUNDRY_PASSWORD=<snipped> \
--env FOUNDRY_ADMIN_KEY=<snipped> \
--env FOUNDRY_HOSTNAME=<snipped> \
--env FOUNDRY_PROXY_PORT=443 \
--env FOUNDRY_PROXY_SSL=true \
--publish 30000:30000/tcp \
--volume foundry-vtt:/data \
-d \
--name foundry-vtt \
felddy/foundryvtt:release
The NGINX file is a simple reverse proxy to port 30000, with a https redirect.
foundryvtt-docker/src/entrypoint.sh
Lines 164 to 191 in 559a5f6
If FOUNDRY_RELEASE_URL
, FOUNDRY_USERNAME
and FOUNDRY_PASSWORD
set, during the installation step/fetching S3 URL, it skipped the initial authentication.
After that, the script won't authenticate again, so there is no cookiejar_file
.
So it will run into L186 and log Unable to apply a license key
.
foundryvtt-docker/src/entrypoint.sh
Line 186 in 559a5f6
By the way, niether
misspelled ;)
Steps to reproduce the behavior:
FOUNDRY_RELEASE_URL
, FOUNDRY_USERNAME
and FOUNDRY_PASSWORD
.If all set, it will still generate the license file.
Entrypoint | 2020-11-02 09:22:30 | [info] Installing Foundry Virtual Tabletop 0.7.5
Entrypoint | 2020-11-02 09:22:32 | [info] Installation not yet licensed.
Entrypoint | 2020-11-02 09:22:32 | [warn] Unable to apply a license key since niether a license key nor credentials were provided. The license key will need to be entered in the browser.
Hi. We have your Foundry VTT felddy docker image installed on a Synology 16+ server. We have 0.7.5 installed. We began to update to the latest 0.7.7, but the docker installation stops after just a few seconds.
Steps to reproduce the behavior:
See above.
The docker installation should not stop.
Clicking the link doesn't work. Copy it into a new browser tab to get an image of the log output:
https://drive.google.com/drive/folders/1MrptUVy6ChITxyPwMqXGitjtqWZ8Lbzs?usp=sharing
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
"Labels": {
"com.foundryvtt.version": "0.7.7",
"org.opencontainers.image.authors": "[email protected]",
"org.opencontainers.image.created": "2020-11-13T16:03:01Z",
"org.opencontainers.image.description": "An easy-to-deploy Dockerized Foundry Virtual Tabletop server.",
"org.opencontainers.image.licenses": "MIT",
"org.opencontainers.image.revision": "acf4d926c2645b9f810a2dff5169580d2354b78b",
"org.opencontainers.image.source": "https://github.com/felddy/foundryvtt-docker.git",
"org.opencontainers.image.title": "foundryvtt-docker",
"org.opencontainers.image.url": "https://github.com/felddy/foundryvtt-docker",
"org.opencontainers.image.vendor": "Geekpad",
"org.opencontainers.image.version": "0.7.7"
},
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
When removing the FOUNDRY_VERSION environment variable, even though it's listed as optional it led to failures on start up because it was missing.
When I set up the Docker container on my Synology NAS, the UI did set it to a default value of 0.6.5 as expected. However, I wanted to remove this variable or else tools such as Watchtower, which auto update containers, would not work properly. Watchtower would update the container, but since it recreates using the same container settings and environment variables, the Foundry software would remain at the previous version, instead of updating to the updated version as intended.
Steps to reproduce the behavior:
When lacking the FOUNDRY_VERSION variable there should be a sane default to fall back to. In this case, the version matching the image I have.
Output when running without FOUNDRY_VERSION explicitly set by the user:
Entrypoint \| 2020-08-27 02:20:34 \| [info] Starting felddy/foundryvtt container v0.6.5 | stdout
Entrypoint \| 2020-08-27 02:20:34 \| [info] Foundry Virtual Tabletop 0.6.5 is installed. | stdout
./entrypoint.sh: line 55: FOUNDRY_VERSION: parameter not set | stdout
foundryvtt-docker/src/launcher.sh
Line 22 in c780e0f
It only checks CONTAINER_PRESERVE_CONFIG
as for now, but didn't check if the file options.json
/admin.txt
exists. So it won't generate the initial config files if CONTAINER_PRESERVE_CONFIG
set to true.
I think it's better to also check if the config files exist, else update/generate.
e.g.:
if [[ "${CONTAINER_PRESERVE_CONFIG:-}" == "true" && -e options.json && -e admin.txt ]]; then
It's more convenient to use if generate the initial configs but preserve it form regen without modifying container env var.
Running with "-e CONTAINER_PRESERVE_CONFIG=true", it generates the initial config files.
After start, modify the options.json
by FVTT setup panel and the change preserves.
FVTT docker container related.
Portainer labels this container as "unhealthy" with the "Failure count" climbing by one every 30 seconds. When I go into the Portainer event list, it just says "Unsupported event". I don't see anything problems in the actual container logs, and the container otherwise runs well. I am currently running containers on a QNAP NAS via Container Station.
2020-11-27 23:11:29 | container | Unsupported event
2020-11-27 23:11:29 | container | Exec instance started
2020-11-27 23:11:29 | container | Exec instance created
Healthy container
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
[~] # docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' felddy/foundryvtt:release
com.foundryvtt.version = "0.7.7"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-11-13T16:03:01Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "acf4d926c2645b9f810a2dff5169580d2354b78b"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.7"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
Entrypoint | 2020-11-28 05:19:06 | [info] Starting felddy/foundryvtt container v0.7.7,
Entrypoint | 2020-11-28 05:19:06 | [info] Foundry Virtual Tabletop 0.7.7 is installed.,
Entrypoint | 2020-11-28 05:19:06 | [info] Not modifying existing installation license key.,
Entrypoint | 2020-11-28 05:19:06 | [info] Setting data directory permissions.,
Entrypoint | 2020-11-28 05:19:10 | [info] Starting launcher with uid:gid as foundry:foundry.,
Launcher | 2020-11-28 05:19:10 | [info] Generating options.json file.,
Launcher | 2020-11-28 05:19:10 | [info] Setting 'Admin Access Key'.,
Launcher | 2020-11-28 05:19:10 | [info] Starting Foundry Virtual Tabletop.,
FoundryVTT | 2020-11-28 05:19:11 | [info] Foundry Virtual Tabletop - Version 0.7.7,
FoundryVTT | 2020-11-28 05:19:11 | [info] Running on Node.js - Version 12.19.0,
FoundryVTT | 2020-11-28 05:19:11 | [info] Loading data from user directory - /data,
FoundryVTT | 2020-11-28 05:19:11 | [info] Application Options:,
{,
"port": 30000,,
"upnp": false,,
"fullscreen": false,,
"hostname": "(hidden)",,
"routePrefix": "foundryvtt",,
"sslCert": null,,
"sslKey": null,,
"awsConfig": null,,
"dataPath": "/data",,
"proxySSL": true,,
"proxyPort": 443,,
"minifyStaticFiles": false,,
"updateChannel": "release",,
"language": "en.core",,
"world": null,,
"serviceConfig": null,,
"isElectron": false,,
"isNode": true,,
"isSSL": false,,
"demo": false,,
"noupdate": false,,
"adminKey": "****************",
},
FoundryVTT | 2020-11-28 05:19:11 | [info] License verification succeeded,
FoundryVTT | 2020-11-28 05:19:12 | [info] Server started and listening on port 30000
Inspecting container includes this:
"State": {
"Dead": false,
"Error": "",
"ExitCode": 0,
"FinishedAt": "2020-11-28T05:18:56.087416684Z",
"Health": {
"FailingStreak": 27,
"Log": [
{
"End": "2020-11-27T23:33:09.088843651-06:00",
"ExitCode": 1,
"Output": "",
"Start": "2020-11-27T23:33:09.001680468-06:00"
},
{
"End": "2020-11-27T23:33:39.184889219-06:00",
"ExitCode": 1,
"Output": "",
"Start": "2020-11-27T23:33:39.092357315-06:00"
},
{
"End": "2020-11-27T23:34:09.290409289-06:00",
"ExitCode": 1,
"Output": "",
"Start": "2020-11-27T23:34:09.189952448-06:00"
},
{
"End": "2020-11-27T23:34:39.393606688-06:00",
"ExitCode": 1,
"Output": "",
"Start": "2020-11-27T23:34:39.297397814-06:00"
},
{
"End": "2020-11-27T23:35:09.489496139-06:00",
"ExitCode": 1,
"Output": "",
"Start": "2020-11-27T23:35:09.398550595-06:00"
}
],
"Status": "unhealthy"
},
"OOMKilled": false,
"Paused": false,
"Pid": 9716,
"Restarting": false,
"Running": true,
"StartedAt": "2020-11-28T05:19:06.401790056Z",
"Status": "running"
}
When using the A/V service, a TURN server is supposed to startup and bind to udp:33478
I've enabled A/V in my world and no TURN server is spawned.
All of a sudden, a previously functional 0.7.9 image stopped working, and gets stuck starting in an endless chown loop. The image starts up, gets to "Setting data directory permissions", and then a whole bunch of chown errors arise.
I am unsure what caused the problem as it was working yesterday and stopped working when I got home today.
Some additional info:
I am running this image inside docker on a Synology NAS, and I set up a user jail so I could allow the GM access to the git repo that hosts our game.
I expected the image to load as usual. A work-around was provided on Foundry Discord, setting the image to 0.7.8 and the FOUNDRY_VERSION configuration variable to 0.7.9 which worked for me.
Please run this command:
docker inspect --format='{{range $k, $v := .Config.Labels}}
{{- printf "%s = \"%s\"\n" $k $v -}} {{end}}' \
felddy/foundryvtt:latest
Paste the results here:
com.foundryvtt.version = "0.7.9"
org.opencontainers.image.authors = "[email protected]"
org.opencontainers.image.created = "2020-12-19T18:22:45Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "d7bbea8063e5cbf8cc93ef114aca843be45d299d"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker.git"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "0.7.9"
Run the container with CONTAINER_VERBOSE
set to true
,and paste any useful
log output here:
Entrypoint | 2020-12-27 22:01:45 | [debug] Timezone set to: UTC
Entrypoint | 2020-12-27 22:01:45 | [info] Starting felddy/foundryvtt container v0.7.9
Entrypoint | 2020-12-27 22:01:45 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.
Entrypoint | 2020-12-27 22:01:45 | [info] Reading configured secrets from: /run/secrets/config.json
Entrypoint | 2020-12-27 22:01:46 | [info] Foundry Virtual Tabletop 0.7.9 is installed.
Entrypoint | 2020-12-27 22:01:46 | [info] Not modifying existing installation license key.
Entrypoint | 2020-12-27 22:01:46 | [info] Setting data directory permissions.
chown: /data/lib_all/i686: No such file or directory
chown: /data/lib_all/libsynotrigger.so: No such file or directory
chown: /data/lib_all/perl5: No such file or directory
chown: /data/lib_all/sharing/plugin/SYNO.SDS.App.SharingUpload.Application.so: No such file or directory
chown: /data/lib_all/sharing/plugin/SYNO.SDS.App.FileStation3.Instance.so: No such file or directory
chown: /data/lib_all/ld-linux.so.2: No such file or directory
chown: /data/lib_all/terminfo: No such file or directory
chown: /data/Data/var/packages/git/etc: No such file or directory
chown: /data/Data/var/packages/git/target: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c9f83a1c.0: No such file or directory
chown: /data/Data/etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/DST_ACES_CA_X6.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/157753a5.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Express_=Class_C=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/UTN_USERFirst_Hardware_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3efd4dc0.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_eBusiness_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/7d5a75e4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Qualified_=Class_QA=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/9f0f5fd6.0: No such file or directory
chown: /data/Data/etc/ssl/certs/cb357862.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Certinomis_-_Autorité_Racine.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/cbeee9e2.0: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Visa_eCommerce_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/0810ba98.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/56657bde.0: No such file or directory
chown: /data/Data/etc/ssl/certs/876f1e28.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2007.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/TC_TrustCenter_Class_3_CA_II.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/b6c5745d.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Comodo_Secure_Services_root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3ee7e181.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Comodo_Trusted_Services_root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/1874d4aa.0: No such file or directory
chown: /data/Data/etc/ssl/certs/f38a011e.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Swisscom_Root_EV_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/9007ae68.0: No such file or directory
chown: /data/Data/etc/ssl/certs/9d520b32.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Equifax_Secure_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Certification_Authority_of_WoSign_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/WoSign_China.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/5620c4aa.0: No such file or directory
chown: /data/Data/etc/ssl/certs/c99398f3.0: No such file or directory
chown: /data/Data/etc/ssl/certs/China_Internet_Network_Information_Center_EV_Certificates_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c5e082db.0: No such file or directory
chown: /data/Data/etc/ssl/certs/790a7190.0: No such file or directory
chown: /data/Data/etc/ssl/certs/bb2d49a0.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ef2f636c.0: No such file or directory
chown: /data/Data/etc/ssl/certs/IGC_A.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Staat_der_Nederlanden_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/cfa1c2ee.0: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_WoSign_ECC_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/861e0100.0: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_External_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c679bc3f.0: No such file or directory
chown: /data/Data/etc/ssl/certs/UTN_USERFirst_Email_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/034868d6.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ACEDICOM_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/e536d871.0: No such file or directory
chown: /data/Data/etc/ssl/certs/024dc131.0: No such file or directory
chown: /data/Data/etc/ssl/certs/8b59b1ad.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/a760e1bd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/65b876bd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Security_Communication_EV_RootCA1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/PSCProcert.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/c5d3212a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/57bbd831.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ae8153b9.1: No such file or directory
chown: /data/Data/etc/ssl/certs/f060240e.0: No such file or directory
chown: /data/Data/etc/ssl/certs/0d1b923b.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Root_CA_Generalitat_Valenciana.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_Disig_Root_R1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/7992b8bb.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/415660c1.1: No such file or directory
chown: /data/Data/etc/ssl/certs/2ab3b959.0: No such file or directory
chown: /data/Data/etc/ssl/certs/RSA_Security_2048_v3.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Buypass_Class_2_CA_1.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/bd1910d4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/1ec4d31a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/381ce4dd.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CNNIC_ROOT.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Sonera_Class_1_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Business_=Class_B=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/8096d0a9.0: No such file or directory
chown: /data/Data/etc/ssl/certs/24ad0b63.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Juur-SK.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/26eaad2f.0: No such file or directory
chown: /data/Data/etc/ssl/certs/NetLock_Notary_=Class_A=_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/CA_Disig.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/StartCom_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/AC_Raíz_Certicámara_S.A..pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Microsec_e-Szigno_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/578d5c04.0: No such file or directory
chown: /data/Data/etc/ssl/certs/WoSign.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/79ad8b43.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b13cc6df.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b8e83700.0: No such file or directory
chown: /data/Data/etc/ssl/certs/667c66d4.0: No such file or directory
chown: /data/Data/etc/ssl/certs/TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H5.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/3b2716e5.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Certplus_Class_2_Primary_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/415660c1.0: No such file or directory
chown: /data/Data/etc/ssl/certs/Certinomis_-_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/fcac10e3.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b7e7231a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/6f2c1157.0: No such file or directory
chown: /data/Data/etc/ssl/certs/592c0a9a.0: No such file or directory
chown: /data/Data/etc/ssl/certs/b42ff584.0: No such file or directory
chown: /data/Data/etc/ssl/certs/812e17de.0: No such file or directory
chown: /data/Data/etc/ssl/certs/19c1fa33.0: No such file or directory
chown: /data/Data/etc/ssl/certs/d9d12c58.0: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_Qualified_Certificates_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/67d559d1.0: No such file or directory
chown: /data/Data/etc/ssl/certs/ApplicationCA_-_Japanese_Government.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/ComSign_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/AddTrust_Public_Services_Root.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/ae8153b9.0: No such file or directory
chown: /data/Data/etc/ssl/certs/5d63b0ae.0: No such file or directory
chown: /data/Data/etc/ssl/certs/S-TRUST_Universal_Root_CA.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/GeoTrust_Global_CA_2.pem: No such file or directory
chown: /data/Data/etc/ssl/certs/d957f522.0: No such file or directory
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.